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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 15, 2011, 21:58 UTC
Message-ID: <7v62ilujya.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0krTY+szqPrE9wxwfK76VBbFXh_Xaz8EyWZayLa_SFQTw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 15 quoted lines

> Hi Junio,
>
> Junio C Hamano writes:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> [...]
>> [...]
>> I do not see an inconsistency here, let alone any "glaring" one.
>
> Yeah, my commit message is totally misleading and unclear.  Yes, all
> the operations make sense to you and me; for a new user who doesn't
> understand how Git works, it's completely inconsistent at a very
> superficial level, no?  The sequence of operations he has to execute
> depends on:
> 1. If he literally specified a single commit or a commit range on the
> command-line.

But we are already in agreement on this point, I think. Didn't I say:

  It is a different story if the sequence were like this:

      $ git cherry-pick foo
      ... conflict happens
      $ edit problematicfile
      $ git add problematicfile
      $ git cherry-pick --continue
      ... This should notice CHERRY_PICK_HEAD and record it.
      ... After that, there is nothing remaining to be done.

  In other words, the user said "I want to replay this commit", the command
  couldn't finish it by itself and asked the user to help resolving the
  conflict, the user resolved and told the command to continue. The command
  should continue recording the result.

  And if "continue" does not work in this sequence, that is a bug worth
  fixing.

in the message you are responding to?

> 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.

I think "rebase -i" works the same way and both are valid ways to tell the command to continue.

Now, multi-commit form of cherry-pick/revert _may_ be buggy (I do not use that form often myself to know if this is the case, though) and may only allow one or the other depending on which commit in the series the user is asked to help, but if that is the case it is a bug in the implementation of the multi-commit form done back in v1.7.2 timeframe.