Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> Prior to v1.7.2-rc1~4^2~7 (revert: allow cherry-picking more than one
> commit, 2010-06-02), 'git cherry-pick' could only pick one commit at a
> time, and it used '.git/CHERRY_PICK_HEAD' to pass on information to a
> subsequent invocation in case of a conflict. While
> '.git/CHERRY_PICK_HEAD' can only keep information about one commit,
> the sequencer uses '.git/sequencer' to persist information in the
> general case.
>
> A problem arises because a single-commit cherry-pick operation can be
> completed successfully using 'git commit'. This removes
> '.git/CHERRY_PICK_HEAD' without informing the sequencer, leaving
> behind a stale sequencer state as a result. We have worked around
> this problem already by prematurely removing the sequencer state in
> d3f4628e (revert: Remove sequencer state when no commits are pending,
> 2011-06-06). However, this gets in the way of our future plan to
> eliminate a glaring workflow inconsistency:
>
> $ git cherry-pick foo
> ... .git/sequencer is created ....
> ... .git/CHERRY_PICK_HEAD is created ...
> ... conflict ...
> .... .git/sequencer is prematurely removed ...
Isn't the real problem that .git/sequencer is created in the first place,
when this form of the command knows it will use CHERRY_PICK_HEAD?
> $ echo "resolved" >problematicfile
> $ git add problematicfile
> $ git commit
> ... .git/CHERRY_PICK_HEAD is removed ...
> $ git cherry-pick --continue
> error: No cherry-pick in progress
This is the right thing to happen, no? There is no in-progress cherry-pick
anymore after that commit. 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, and the user resolved and recorded the result.
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.
> $ git cherry-pick foo..bar
> ... .git/sequencer is created ....
> ... CHERRY_PICK_HEAD is created ...
> ... conflict in bar~1 ...
> $ echo "resolved" >problematicfile
> $ git add problematicfile
> $ git commit
> ... CHERRY_PICK_HEAD is removed ...
> $ git cherry-pick --continue # Success!
This again is the right thing to happen, as the user had to help the
command while replaying bar~1 and then told it to continue, which
successfully replayed bar.
I do not see an inconsistency here, let alone any "glaring" one.
--
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