Hi, Jonathan Nieder writes: > Ramkumar Ramachandra wrote: >> This is perfect but for the fact that 'git reset --hard' doesn't blow >> away the sequencer state. Why I haven't implemented that yet: should >> ONLY a hard reset blow away the state? > > I don't know. What do you think? I personally don't think any other kind of reset would warrant blowing away the sequencer state. > The constraints I see are: > > 1. outside scripts that use "git cherry-pick" should continue to work > > 2. as a small indication that that's vaguely possible, unrelated parts > of the test suite should not need to be patched I don't see how this is possible. I'm tempted to say that we should call this new cherry-picking mechanism with the sequencing functionality something else like "git sequencer"; then it's possible to avoid breaking existing scripts. > 3. when a person uses commands like "git reset --hard" without > _intending_ to blow away the sequencer state, it should be possible > to get the sequencer state back. I like your suggestion here -- simply move .git/sequencer to .git/sequencer-old or similar :) > For dealing with "git rebase --interactive" and similar porcelain-ish > scripts, the CHERRY_PICK_HEAD code-path has its own trick of falling > back to traditional behavior when the GIT_CHERRY_PICK_HELP environment > variable is set (see v1.5.4-rc0~106^2~1, revert/cherry-pick: Allow > overriding the help text by the calling Porcelain, 2007-11-28). Ah, I see. -- Ram -- 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