Ramkumar Ramachandra wrote: > Protect the sequencer state from accidentally being stomped by a new > cherry-pick or revert invocation by ensuring that an existing one > isn't in progress. I first read this as "an existing sequencer state isn't in progress". But anyway, if I understand correctly the goal isn't to protect the sequencer state from corruption but to protect the user from forgetting about a pending cherry-pick. > While this patch would normally be expected to > break many tests, the earlier patches "reset: Make hard reset remove > the sequencer state" and "revert: Remove sequencer state when no > commits are pending" make sure that they don't. Why would I expect a nice change to break tests? I suppose you mean: "A naive version of this would break the following established way of working: git cherry-pick X; # has conflicts git reset --hard; # no, no! git cherry-pick Y Or even: git cherry-pick X; # has conflicts # ... resolve ... git commit git cherry-pick Y But a previous patch takes care of that by making "git reset --hard" cancel the pending cherry-pick and by making "git commit" clean up after a pending cherry-pick when making the commit that would finish it." The above text quoted with ">" describes the main impact of the change. The subject line, on the other hand, describes a less important part: > [Subject: revert: Introduce --reset to remove sequencer state] Is that fixable? Maybe this could be split into two patches (since it does two different things), or maybe the subject line could be tweaked to describe both. [...] > Ensure that the "rebase -i" script which invokes cherry-pick or revert > doesn't change its behavior by using '--reset' to to clear the state > after every failed pick. This should be avoidable by noticing that commands like "rebase -i" use GIT_CHERRY_PICK_HELP to clobber our nice instructions about how to resume a cherry-pick anyway and therefore are unlikely to need cherry-pick --continue/--abort facilities, no? Regards, Jonathan -- 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