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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 13, 2011, 23:23 UTC
Message-ID: <7vpqgvmwtl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1321181181-23923-4-git-send-email-artagnon@gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 22 quoted lines

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

Show 6 quoted lines

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

Show 9 quoted lines

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