[gpm]

Not 100% sure I understand what you're saying, but I think the answer is "yes".

You can modify any* commit in `jj` regardless of whether it has commits on top of it at any time. Either by another commit into it, or by directly checking out the commit and editing the source tree. If this creates conflicts with commits on top of it `jj` just records those commits as having conflicts/adds conflict markers without interrupting the workflow.

* Commits pushed to remotes are marked immutable so you have to pass an extra flag to say ignore that and modify them anyways. Which you generally wouldn't want to do.

[verdverm]

So if I push a commit update, and then someone else pushes a commit to one I build on, and there is a conflict...

How does recording the conflict, but not introducing it (if I'm understanding correctly), ... how does this affect my build/ci workflow?

[gpm]

If I understand you correctly we're imagining you pulled a repo with main at commit A. You added commit B on top of A. Someone else added commit C on top of A to main on the remote, and you're asking what happens?

Nothing until you pull and rebase B on top of C (two distinct steps). Once B is on top of C, when B is checked out there will be conflict markers in the source tree that will presumably break your build until you resolve the conflict (unless the conflict is in README or something).

My CI workflow has always been on top of a git based forge. As far as the forge is concerned jj is git and absolutely nothing changes with regards to that.

[verdverm]

A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches)

Let's remove the merge conflict and keep the commits in alphabetical order

B pushes a breaking change, I push a commit to C without knowing.

Are my builds and PRs now at the mercy of changes and events outside of my control?

(my hunch is that there are a bunch of confusing situations in jj like git, and that being different enough will cause user churn and people will stick with the tool they already understand the quirks of)

[gpm]

You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it.

> iiuc jj uses stacked commits instead of branches

Locally jj doesn't really use branches, you can just create a commit on top of any other commit without creating a branch. It does represent branches (it calls them "bookmarks" for whatever reason) and pushing is pushing a bookmark to a git-branch on the remote.

> Are my builds and PRs now at the mercy of changes and events outside of my control?

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.

[verdverm]

We don't use rebase at all, it's forbidden.

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?

[gpm]

> 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.