Ramkumar Ramachandra wrote: > Sounds nice in theory, but how do we do it? Remove the state at "git > commit" time? I've already thought about the problem and presented my > arguments here [1]. > > [1]: http://article.gmane.org/gmane.comp.version-control.git/177465 For reference: > My sequencer state was blown away just because of a stray > .git/remove-sequencer-state-after-commit from a previous operation! > This is horrible. One can then argue: the file should only ever abort > *that* sequencer operation, and now we run into the problem of > assigning a UID for each sequencer operation. Unnatural and ugly. > Conclusion: Making "git commit" remove the sequencer state is WRONG. That is a compelling argument for not using a .git/remove-sequencer-state-after-commit file, but I don't see why one would want such a file anyway. Why can't "git commit" just call a function or use a command that examines .git/sequencer and looks at how many commits are left to pick? Looking at it from the other side, "My sequencer state was blown away" is a bit dramatic. If it's a problem in "git commit", why isn't it a problem in "git reset", too? If I just commited after resolving a conflict from applying the last commit in the series, what cherry-pick sequence state is going to be useful to me now? And how is this any less unnatural than making the 'abort cherry-pick' facility unusable when and only when cherry-picking the last commit in a sequence? I don't get it. -- 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