Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> Hi Junio,
>
> Junio C Hamano writes:
>> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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.
--
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