> Since jj does not have branches, it sounds like we are forced into the rebase environment?
No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases.
While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists on each leaf commit in the source control tree being tagged with a name it calls a branch, jj is perfectly happy to have leaves in the source control tree where you haven't given them a branch-name.
> This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...
The behaviour here is the exact same between git and jj. If both you and a coworker push to the same remote branch you have to handle conflicts before pushing with either VCS. If both you and a coworker push to different remote branches and then you submit the change through a pull request you see conflicts when you try to merge the branches (or a reasonable forge like github will test merging behind the scenes and surface it early).
> Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
No. jj never shifts conflict resolution left. JJ does sometimes shift conflicts right, allowing you to defer fixing the conflict until later.
No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases.
While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists on each leaf commit in the source control tree being tagged with a name it calls a branch, jj is perfectly happy to have leaves in the source control tree where you haven't given them a branch-name.
> This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...
The behaviour here is the exact same between git and jj. If both you and a coworker push to the same remote branch you have to handle conflicts before pushing with either VCS. If both you and a coworker push to different remote branches and then you submit the change through a pull request you see conflicts when you try to merge the branches (or a reasonable forge like github will test merging behind the scenes and surface it early).
> Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
No. jj never shifts conflict resolution left. JJ does sometimes shift conflicts right, allowing you to defer fixing the conflict until later.