Thread (17 messages) flat view 17 messages, 2 authors, 2016-06-15

Re: [PATCH 5/5] sequencer: revert d3f4628e

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:52:23

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help