Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Ramkumar Ramachandra wrote: > >> Since d3f4628e (revert: Remove sequencer state when no commits are >> pending, 2011-07-06), the sequencer removes the sequencer state before >> the final commit is actually completed. This design is inherently >> flawed, as it will not allow the user to abort the sequencer operation >> at that stage. Instead, make 'git commit' notify the sequencer after >> every successful commit; the sequencer then removes the state if no >> more instructions are pending. > > Sorry, I'm getting lost in all the words. I suspect you are saying > “d3f4628e was trying to solve such-and-such problem, but its fix was > problematic because it removes the data that a hypothetical "git > cherry-pick --abort" command would need to work. Back out that > change and adopt the following instead.” It still is unclear why "removing the sequencer state when no more insns are pending" is so necessary that the codebase needs to bend backwards to support that in the first place. What problem is d3f4628e really trying to solve? If "who is responsible for removing a stale state" is the issue it tries to address, Wouldn't it be much cleaner to make "sequencer continue" notice that state and silently succeed, saying "I am done"? -- 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