4 ms·

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 comm

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 2y ago
> I still don't understand the way jj handles conflicts. See https://jj-vcs.github.io/jj/latest/conflicts/ 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 2y ago
  > See https://jj-vcs.github.io/jj/latest/conflicts/ 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 2y ago
    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 2y ago
      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 2y ago
        > 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 2y ago
        > 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 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.

martinvonz 2y ago

> I still don't understand the way jj handles conflicts. See https://jj-vcs.github.io/jj/latest/conflicts/ 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 2y ago
> See https://jj-vcs.github.io/jj/latest/conflicts/ 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 2y ago
  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 2y ago
    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 2y ago
      > 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 2y ago
      > 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 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.