Re: [PATCH 3/7] sequencer: handle single-commit pick as special case

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Nov 16, 2011, 06:30 UTC
Message-ID: <CALkWK0mW4MOw_vvqRengbDrf4sd8NJZptr57b8LKDmfAhxevpA@mail.gmail.com>
In-Reply-To: <7v62ilujya.fsf@alter.siamese.dyndns.org>

Hi Junio,

Junio C Hamano wrote:

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
> But we are already in agreement on this point, I think. Didn't I say:

Yes, yes. I was just thinking out loud so it'll help me write a new commit message. Sorry for the noise.

Show 19 quoted lines

>> 2. In the case of multi-commit picking, there's an additional layer of
>> decision making: did the conflict occur in the last commit in the
>> range?
>
> Again, it would be the same thing. If the implementation forces that
> decision, that would be a bug, no?
>
> My understanding is that multi-commit form of cherry-pick and revert
> intended to allow two forms of "user done helping and telling the command
> to continue" at any stage, be it the first, in the middle, or the last
> operation in a series:
>
>  - User resolves, adds and commits, and then tells the command to
>   continue. The command notices that the user has committed, and goes on
>   to the next task; or
>
>  - User resolves, adds, and then tells the command to continue. The
>   command notices that the user has not committed, makes a commit and
>   goes on to the next task.

Yep, this is exactly how it'll work after the series :D

Thanks.

-- Ram