Does git-stack help with conflicts at all?

[alan-nf]

I see that git-stack is not setup to resolve conflicts. From the README:

Non-features
Conflict resolution: git-stack will give up and you'll have to use git rebase yourself to resolve the conflict.

Okay, cool. So how do you git rebase to resolve a conflict? I tried doing an interactive rebase and resolving the conflict, which obviously split my branch in two. I then did a git stack --repair to unify the split branches but got an error about cherry-pick conflicts. Am I understanding this correctly and the second there is a conflict you have to do ALL operations to get back into a usable state outside git-stack? If so, the utility of this seems limited, since I have to make amending older commits and repairing the branches completely manually part of my workflow.

[epage]

I then did a git stack --repair to unify the split branches but got an error about cherry-pick conflict

Could you provide more details of --repair not working? I'd be interested in understanding if that is case where I would expected git-stack to fail or if there is a bug for us to fix.

[alan-nf]

Sorry, I lost track of what I was originally reporting, but here's what I can reproduce now:

➜ git-stack-test-2 git:(feature3) git stack

main (no remote) Initial commit
⌽ a8bee03 initial feature2 work
⌽ feature2 (ready) later feature2 work
⌽ b981fa4 Feature 3 work
⌽ feature3 fixup! initial feature2 work

➜ git-stack-test-2 git:(feature3) git stack --rebase --dry-run

main (no remote) Initial commit
⌽ a8bee03 initial feature2 work
⌽ 1fe976a fixup! initial feature2 work
⌽ feature2 (ready) later feature2 work
⌽ feature3 Feature 3 work

git stack --rebase gives cherry-pick conflict error, so I do it manually:
➜ git-stack-test-2 git:(feature3) git rebase -i main

pick a8bee03 initial feature2 work
fixup 1fe976a fixup! initial feature2 work
pick 426f79b later feature2 work
pick b981fa4 Feature 3 work

<resolve conflicts>

➜ git-stack-test-2 git:(feature3) git stack

main (no remote) Initial commit
├─┐
│ ⌽ a8bee03 initial feature2 work
│ ⌽ feature2 (ready) later feature2 work
│
⌽ 34d85b9 initial feature2 work
⌽ a2e482e later feature2 work
⌽ feature3 (ready) Feature 3 work

➜ git-stack-test-2 git:(feature3) git stack --repair
(doesn't seem to do anything?)

main (no remote) Initial commit
├─┐
│ ⌽ a8bee03 initial feature2 work
│ ⌽ feature2 (ready) later feature2 work
│
⌽ 34d85b9 initial feature2 work
⌽ a2e482e later feature2 work
⌽ feature3 (ready) Feature 3 work

[epage]

Do you have autofixup enabled?

It looks like the cherry-pick conflict is coming from moving the fixup commit.

As for why the --repair isn't happening is because we right now have a crude algorithm that just checks if the tree-id is the same. This catches when what you are based on caused the conflict. In this case, its a fixup that caused the conflict so the tree-ids are different. We need to find more but safe ways of detecting divergent trees.

[alan-nf]

Do you have autofixup enabled?

I don't think so?

It looks like the cherry-pick conflict is coming from moving the fixup commit.

Yep for sure

In this case, its a fixup that caused the conflict so the tree-ids are different. We need to find more but safe ways of detecting divergent trees.

Yeah, and that's a tough problem. I'm using git-branchless atm and it mostly accomplishes this but it isn't always successful at this detection, so I have to manually massage things.

[alan-nf]

And by massage things I mean manually force re-assign branches to the moved commits, and recursively hide branches that have been rewritten that it didn't detect as rewritten.

[epage]

I forgot, fixup does a move but not squash by default. This can be disable in one-off ways with --fixup ignore. Having full rebase capabilities will be important.

[epage]

Am I understanding this correctly and the second there is a conflict you have to do ALL operations to get back into a usable state outside git-stack? If so, the utility of this seems limited, since I have to make amending older commits and repairing the branches completely manually part of my workflow.

The usefulness depends on your workflow. I use git-stack all the time but rarely run into cases where I have to manually merge two branches (as in I'm not even running --repair).

The big reason we don't deal with conflict resolution is that its a stateful operation directly on the working tree. We don't operate on the working tree and I'm not aware of a way to plug into git's state management an alternative stateful operation. If people have ideas on resolving these problems or bypassing them, I'd be more open to conflict resolution.

@arxanas how does git-branchless handle conflicts?

[arxanas]

• If you run git move or git sync (or git amend, or git restack, ...) and it would produce a conflict, it instead warns you and aborts. You have to pass -m/--merge to initiate conflict resolution.
• When not invoked with --merge, git sync will still sync all commit stacks that don't have conflicts, and just warn you about the ones that do.
• Merge conflicts can only be resolved on-disk, not in-memory (not for any principled reason, just no one has made a good UI for it yet; see also Add a TUI for editing diffs jj-vcs/jj#48).
• To resolve conflicts, git-branchless generates a rebase plan and shoves it in the .git directory, then runs git rebase --continue to start the rebase, which starts the rebase and proceeds to the first merge conflict. They can then resolve the merge conflicts and run git rebase --continue or git rebase --abort as appropriate.
  • In retrospect, I probably could have done this by setting GIT_SEQUENCE_EDITOR to something clever and then invoking git rebase directly, instead of messing with the potentially unstable on-disk rebase state.
  • That being said, the on-disk rebase state is at least a little stable: there's comments in the rebase code explaining how they handled certain situations for when Git was upgraded in the middle of a rebase.

The code to initialize the rebase is here: https://github.com/arxanas/git-branchless/blob/1b54cd9b18bd516417792329211a7833554c8627/src/core/rewrite/execute.rs#L740-L746

[arxanas]

Here's the documentation for resolving merge conflicts, which includes examples of the behavior that you would see:

• git move: https://github.com/arxanas/git-branchless/wiki/Command:-git-move#resolving-merge-conflicts
• git sync: https://github.com/arxanas/git-branchless/wiki/Command:-git-sync#resolving-merge-conflicts

[epage]

To resolve conflicts, git-branchless generates a rebase plan and shoves it in the .git directory, then runs git rebase --continue to start the rebase, which starts the rebase and proceeds to the first merge conflict. They can then resolve the merge conflicts and run git rebase --continue or git rebase --abort as appropriate.

Doesn't this require the rebase plan to be linear or is the on-disk format more flexible than the plan shown in the editor?

[arxanas]

Doesn't this require the rebase plan to be linear or is the on-disk format more flexible than the plan shown in the editor?

The editor can do non-linear merges, as it's necessary to support the --preserve-merges/--rebase-merges options. This is what the comment says when you open rebase -i:

# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.

label and reset are sufficient primitives to implement non-linear rebase plans ourselves. You can see the logic for building the plan here: https://github.com/arxanas/git-branchless/blob/1b54cd9b18bd516417792329211a7833554c8627/src/core/rewrite/plan.rs#L273-L282

There are some interesting consequences. You can rebase multiple unrelated subgraphs in a single rebase by reseting to an unrelated commit. I think the git restack command actually does that, so if you pass --merge to git restack, you might have to resolve merge conflicts in different sub-graphs during the same rebase session!

[arxanas]

You can also just use exec <cmd> as a step. git-branchless does that when it needs to do something in between rebase steps: https://github.com/arxanas/git-branchless/blob/1b54cd9b18bd516417792329211a7833554c8627/src/core/rewrite/plan.rs#L104-L118. That being said, I don't see why git-stack would need to do those.