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 ?

CodePudding user response：

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.