2

I know that --quit does not change your HEAD pointer, so any commits made successfully during a rebase or cherrypick are still there.

But what I'm unsure of is, in case a conflict happened during a cherry-pick or a rebase, whether using --quit clear the changes brought about by the conflict, such as the successfully added changes, the conflict markers in the working directory, the multiple versions in the index etc ?

The git rebase documentation has the following:

--quit Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.

the cherry-pick documentation is less clear about the effects on the index and work tree:

--quit Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.

But this otherwise excellent answer in SO has the following:

But if you choose --quit, Git terminates the rebase without moving HEAD, so that you wind up with:

but a clean index and work-tree. So you don't have to be clever enough to attach a branch name before the --quit.

So which is it ? I know that in a merge --quit will not clear the mess that a merge conflict makes in your index and work tree, it just abandons the merge head state. is it different in case of a cherry pick or a rebase ?

Houidi mohamed amin
  • 45
  • 5

1 Answers1

1

It really depends on the state you had at the time you issue the --quit: Git just stops here. I'll update the other answer to indicate that you can then git reset --hard to make it "clean" if you want, or leave it "dirty" if you want.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Oh hello there! Small world huh. I just wanted to confirm, because usually in a merge conflict, your index and work tree are not clean at all, unless you do it yourself and then quit. So thank you so much for clearing that out. I should mention that I tried to make an edit to the answer, and it said the edit queue is full. – Houidi mohamed amin Apr 14 '22 at 23:45