Ramkumar Ramachandra wrote: > Revert d3f4628e (revert: Remove sequencer state when no commits are > pending, 2011-06-06), because this is not the right approach. Instead > of increasing coupling between the sequencer and 'git commit', a > unified '--continue' that invokes 'git commit' on behalf of the > end-user is preferred. Forgive me for forgetting: what is the problem that d3f4628e was going to resolve (i.e., right approach to what)? What is this increased coupling, and why do we want to avoid it? Is "to prefer" another word for "to implement"? Who is being united by this new --continue switch? Is this patch just reverting a previous patch? If so, why doesn't the commit message use the usual format Revert "<commit message>" This reverts commit <unabbreviated object name>. <explanation> ? > sequencer.c | 12 +----------- > t/t3510-cherry-pick-sequence.sh | 24 ------------------------ > 2 files changed, 1 insertions(+), 35 deletions(-) When changing behavior, it's more comforting to modify tests to describe the new behavior than to just get rid of them. :) To sum matters up: with a new commit message, patch 1 seems likely to be ready. Patches 2-5 seem to need more work --- it's not clear to me yet what they are supposed to do. Hope that helps, 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