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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html