Since jj does not have branches, it sounds like we are forced into the rebase environment?
With git, I can push my changes without a force, regardless of what the work I build on does
I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding activities. CUE suffers from this as well. The biggest pushback I hear is about being able to wrap their heads around it. Devs seem to be largely burnt out on tooling changes right now, we left that hype cycle as the ai/agent cycle was emerging
> I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
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...
Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
> 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.
Since jj does not have branches, it sounds like we are forced into the rebase environment?
With git, I can push my changes without a force, regardless of what the work I build on does
I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding activities. CUE suffers from this as well. The biggest pushback I hear is about being able to wrap their heads around it. Devs seem to be largely burnt out on tooling changes right now, we left that hype cycle as the ai/agent cycle was emerging
> I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
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...
Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?