[conradludgate]

I still don't understand the way jj handles conflicts. If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push?

Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing?

[martinvonz]

> I still don't understand the way jj handles conflicts.

See https://jj-vcs.github.io/jj/latest/conflicts/.

> If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push?

We error out if you try to push conflicts because the Git remote would probably not know how to interpret them. We will probably add an option to allow it later because it can be useful to be able to share conflicts with others if you know that they're also using jj.

> Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing?

You can still do that. Hopefully the above answers your question.

[glandium]

> See https://jj-vcs.github.io/jj/latest/conflicts/.

Honestly, this page doesn't really make a compelling case as to how checking out the commit with a conflict and amending is better than git rebase/whatever --continue. Overall, it's also quite abstract. Concrete examples would be deeply appreciated.

[necauqua]

It's very obviously miles better because there's no global rebase state?.

So you can just leave the conflict there an go work on something else then come back.

Also it's not sequential like --continue you've mentioned.

Also you can rebase the conflicting commits themselves, and by doing so potentially resolve the conflict and the resolution will propagate.

For example manually undoing the rebase while useless (there's jj undo after all) shows that.

[conradludgate]

To me it still all seems confusing. I don't have a good mental model for it.

How does it handle things like `git rebase -x 'make fmt'` which might edit each rebased commit automatically, or `git rebase -x 'make lint'` which might fail but not leave a conflict marker. I didn't see any docs for exec in jj rebase so I guess this feature doesn't work

There's also no examples for how you work out which commit has a conflict marker. It's probably obvious in jj status but it would be nice to document, as I'm not yet interested in spending the time to test it.

And I imagine it all breaks in colocated repos too (I need submodule support, and I want to use gh cli etc)

[steveklabnik]

> How does it handle things like `git rebase -x

It currently doesn't; `jj run` is a command to do this, separate from rebase, which has a PR open but hasn't been merged yet.

> There's also no examples for how you work out which commit has a conflict marker

Every bit of UI shows a bright red (conflict) on conflicted changes, it's hard to miss.

> And I imagine it all breaks in colocated repos too

It doesn't break in colocated repos in the sense that the feature works when you're working with jj, but you'd want to update your submodules and use gh cli on non-conflicted things.

[arxanas]

> To me it still all seems confusing. I don't have a good mental model for it. > > How does it handle things like `git rebase -x 'make fmt'` which might edit each rebased commit automatically, or `git rebase -x 'make lint'` which might fail but not leave a conflict marker. I didn't see any docs for exec in jj rebase so I guess this feature doesn't work

As a mental model, you can pretend that a commit with a conflict in it has suspended the subsequent rebase operation for descendant commits. When you resolve the conflicts in that commit, it's as if jj automatically resumed the rebase operation for the descendant commits. This process repeats until you've applied all of the rebased commits and resolved all of the conflicts (or not, if you decide to not resolve all of the conflicts).

Today, you can write something like

    for commit in "$(jj log -T ...)"; do jj edit "$commit" && make fmt; done

which would also edit the commits automatically. It's probably not too hard to break out of the loop when the first conflict is detected to match the Git workflow more directly. (I can figure it out if you end up being interested.)

> There's also no examples for how you work out which commit has a conflict marker. It's probably obvious in jj status but it would be nice to document, as I'm not yet interested in spending the time to test it.

Does this overview help? https://jj-vcs.github.io/jj/v0.26.0/tutorial/#conflicts

> And I imagine it all breaks in colocated repos too (I need submodule support, and I want to use gh cli etc)

It depends on the exact subset of features you need.

- jj can't update submodules, which works for some workflows but not others.

- Generally speaking, you can use the `gh` CLI reasonably well alongside jj. In jj, it's common to create commits not addressed by any branch, but `gh` doesn't support those well. You can either try to adopt your Git workflows directly and always use branches, or else you'll need to make sure to create the branch just-in-time before performing a `gh` invocation that would need a branch.