From: Jonathan Nieder <jrnieder@gmail.com>
Date: Tue, 12 Jul 2011 20:30:11 GMT
Subject: Re: [PATCH 16/17] revert: Introduce --reset to remove sequencer state
Message-ID: <20110712203011.GF14909@elie>
In-Reply-To: <1310396048-24925-17-git-send-email-artagnon@gmail.com>

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