Re: [PATCH] Fix revert --abort on Windows

[Johannes Sixt <j.sixt@viscovery.net>]

Am 11/23/2011 11:04, schrieb Jonathan Nieder:
> ... "git reset --merge <commit>" renames the
> .git/sequencer directory as a secondary effect --- after moving to
> <commit>, or so the logic goes, it is unlikely but possible that the
> caller of git reset wants to continue the series of cherry-picks that
> was in progress, so git renames the sequencer state to
> .git/sequencer-old to be helpful while allowing the cherry-pick to be
> resumed if the caller did not want to end the sequence after all.
> ...
> By the way, as the length of [this paragraph] might
> have hinted, I am not convinced that allowing "git reset --hard" as an
> escape route from a cherry-pick sequence was very sensible.  It
> _would_ be nice to have a command to return to a known state,
> discarding progress in all pending multiple-command guided workflows
> (am, rebase, bisect), but git reset is not that command.

IMO, it doesn't make sense that git-reset aborts a cherry-pick sequence:
When I messed up a difficult conflict in the middle of a cherry-pick
sequence, it might be useful to be able to 'git reset --hard && git
cherry-pick that-one-commit' to restart the conflict resolution.

(But does a single-commit cherry-pick during a multi-commit cherry-pick
work to begin with?)

-- Hannes