4 ms·

I would think the obvious answer is how jj deals with merge conflicts. In git, if you get a conflict, you feel like you have to resolve it now. With jj, most

I would think the obvious answer is how jj deals with merge conflicts. In git, if you get a conflict, you feel like you have to resolve it now. With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. A conflict is not at all a blocker.

touristtam 1y ago
> With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. Sorry? You what? How do you know which bit from which source goes where?
- BeetleB 1y ago
  Here's a typical scenario. You do a git pull, just so your branch isn't so out of sync. Immediately you get merge conflicts. You then tell jj "Hey, I'll deal with this later", and make a branch off of the last commit that was conflict free and continue your work there. jj stores the conflict as is, but your branch is conflict free. When you feel you have the energy to deal with the conflict, you switch to the branch that has the conflict, and fix the issue(s). Then you can manipulate the graph (rebase, whatever) so you can have everything in one branch - your changes and the changes you pulled in.
  - 1718627440 1y ago
    So you essentially do a fast-forward until the first commit with a merge commit and then take the previous one? Sounds like something that could also become a flag for git merge.
    - steveklabnik 1y ago
      Git won’t let the portion of the branch that’s still conflicted remain in conflict while you go and work on the other part.
      - 1718627440 1y ago
        I would just abort the conflict resolution.
        steveklabnik 1y ago
        Then you’re back to the state before the rebase. Which is fine, the point is just that they’re not equivalent!
        1718627440 1y ago
        Yes. What's the equivalent would be to just keep the successfully rebased part. Right now you need to do keep the ref yourself. > Sounds like something that could also become a flag for git merge.
    - riwsky 1y ago
      No. The GP making a commit off of the first non-conflict isn’t the essence of the feature he’s talking about, just an example of what he can do next. He’d also be free to edit upstream to not commit, or split a change in two so that parts unrelated to the conflict are in their own change. The big idea is that he doesn’t need to blindly decide that before seeing what the conflict is.
  - EMM_386 1y ago
    > When you feel you have the energy to deal with the conflict So you just kick the can down the road and end up with possibly an even more difficult conflict resolution?
    - BeetleB 1y ago
      > So you just kick the can down the road and end up with possibly an even more difficult conflict resolution? That sentiment is true for pretty much anything in life one may decide to defer till later :-) More concretely, it's often not hard to tell if deferring it will make it worse, or merely the same. The whole point of version control is to give your mind some peace in not worrying about things ("Let's make this change and we can always revert if it doesn't work out"). Conflicts are no different. There's no fundamental reason a conflict needs to be treated like an emergency.
    - sunshowers 1y ago
      Or none at all, if you decide to abandon that work (as has happened to me a bunch).
  - MangoToupe 1y ago
    Isn't this equivalent to simply hard resetting to before the pull? (Or the commit before the conflict?) Plus then you don't end up with an extraneous branch.
nocman 1y ago
> In git, if you get a conflict, you feel like you have to resolve it now. I guess I view that as a positive rather than a negative. I'm not saying that dealing with merge conflicts is a picnic -- it isn't. I just find it difficult to believe that ignoring them and resolving them later will improve the situation in the long run.
- hellcow 1y ago
  It's not about "ignoring" conflicts. In jj you're often working with stacked diffs, and merge conflicts can impact a dozen "branches" all at once. This is trivial to resolve in jj and a nightmare in git. It lets you work on them one piece at a time and upon resolving it, instantly see the conflicts fixed across all your branches at once.
- steveklabnik 1y ago
  It’s about giving you choice. If you want to then fix them immediately, you can. But you don’t have to if you don’t want to. But really, it’s about something deeper: rebase is a first-class operation in memory, and not a serious of patch applications via the file system. They’re therefore lightning quick, and will always succeed, which is nice. If you get partway through resolving a conflict and want to change to something else for some reason, that’s possible and simple.
- raylu 1y ago
  the thing about rebasing/cherry-picking (including just popping the stash) in git is that you only have 2 choices: fix the conflict now or abandon the entire rebase/cherry-pick with jj, you have the option to fix half of it and come back later. you can take a look and see how bad the conflicts are if you go a certain route and compare to another option
  - skydhash 1y ago
    Are you using your editor or a special software/plugin for resolving conflicts. I used Sublime Merge in the patch, but now I’m using Magit+ediff. Resolving conflicts is quite trivial in that case. And I can always ‘rebase -i’ to revert some of the decisions I’ve taken.

touristtam 1y ago

> With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. Sorry? You what? How do you know which bit from which source goes where?

BeetleB 1y ago
Here's a typical scenario. You do a git pull, just so your branch isn't so out of sync. Immediately you get merge conflicts. You then tell jj "Hey, I'll deal with this later", and make a branch off of the last commit that was conflict free and continue your work there. jj stores the conflict as is, but your branch is conflict free. When you feel you have the energy to deal with the conflict, you switch to the branch that has the conflict, and fix the issue(s). Then you can manipulate the graph (rebase, whatever) so you can have everything in one branch - your changes and the changes you pulled in.
- 1718627440 1y ago
  So you essentially do a fast-forward until the first commit with a merge commit and then take the previous one? Sounds like something that could also become a flag for git merge.
  - steveklabnik 1y ago
    Git won’t let the portion of the branch that’s still conflicted remain in conflict while you go and work on the other part.
    - 1718627440 1y ago
      I would just abort the conflict resolution.
      - steveklabnik 1y ago
        Then you’re back to the state before the rebase. Which is fine, the point is just that they’re not equivalent!
        1718627440 1y ago
        Yes. What's the equivalent would be to just keep the successfully rebased part. Right now you need to do keep the ref yourself. > Sounds like something that could also become a flag for git merge.
  - riwsky 1y ago
    No. The GP making a commit off of the first non-conflict isn’t the essence of the feature he’s talking about, just an example of what he can do next. He’d also be free to edit upstream to not commit, or split a change in two so that parts unrelated to the conflict are in their own change. The big idea is that he doesn’t need to blindly decide that before seeing what the conflict is.
- EMM_386 1y ago
  > When you feel you have the energy to deal with the conflict So you just kick the can down the road and end up with possibly an even more difficult conflict resolution?
  - BeetleB 1y ago
    > So you just kick the can down the road and end up with possibly an even more difficult conflict resolution? That sentiment is true for pretty much anything in life one may decide to defer till later :-) More concretely, it's often not hard to tell if deferring it will make it worse, or merely the same. The whole point of version control is to give your mind some peace in not worrying about things ("Let's make this change and we can always revert if it doesn't work out"). Conflicts are no different. There's no fundamental reason a conflict needs to be treated like an emergency.
  - sunshowers 1y ago
    Or none at all, if you decide to abandon that work (as has happened to me a bunch).
- MangoToupe 1y ago
  Isn't this equivalent to simply hard resetting to before the pull? (Or the commit before the conflict?) Plus then you don't end up with an extraneous branch.

nocman 1y ago

> In git, if you get a conflict, you feel like you have to resolve it now. I guess I view that as a positive rather than a negative. I'm not saying that dealing with merge conflicts is a picnic -- it isn't. I just find it difficult to believe that ignoring them and resolving them later will improve the situation in the long run.

hellcow 1y ago
It's not about "ignoring" conflicts. In jj you're often working with stacked diffs, and merge conflicts can impact a dozen "branches" all at once. This is trivial to resolve in jj and a nightmare in git. It lets you work on them one piece at a time and upon resolving it, instantly see the conflicts fixed across all your branches at once.
steveklabnik 1y ago
It’s about giving you choice. If you want to then fix them immediately, you can. But you don’t have to if you don’t want to. But really, it’s about something deeper: rebase is a first-class operation in memory, and not a serious of patch applications via the file system. They’re therefore lightning quick, and will always succeed, which is nice. If you get partway through resolving a conflict and want to change to something else for some reason, that’s possible and simple.
raylu 1y ago
the thing about rebasing/cherry-picking (including just popping the stash) in git is that you only have 2 choices: fix the conflict now or abandon the entire rebase/cherry-pick with jj, you have the option to fix half of it and come back later. you can take a look and see how bad the conflicts are if you go a certain route and compare to another option
- skydhash 1y ago
  Are you using your editor or a special software/plugin for resolving conflicts. I used Sublime Merge in the patch, but now I’m using Magit+ediff. Resolving conflicts is quite trivial in that case. And I can always ‘rebase -i’ to revert some of the decisions I’ve taken.