From: Jay Soffian <jaysoffian@gmail.com>
Date: Sun, 20 Feb 2011 02:29:28 GMT
Subject: Re: [PATCH v3 1/4] Introduce CHERRY_PICK_HEAD
Message-ID: <AANLkTik7cfihdu5-0pvgkq1u7kVShEqnjzh07T+5pU16@mail.gmail.com>
In-Reply-To: <7vipwibfc5.fsf@alter.siamese.dyndns.org>

On Thu, Feb 17, 2011 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> diff --git a/builtin/merge.c b/builtin/merge.c
>> index 9403747..454dad2 100644
>> --- a/builtin/merge.c
>> +++ b/builtin/merge.c
>> @@ -971,6 +971,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>>               else
>>                       die("You have not concluded your merge (MERGE_HEAD exists).");
>>       }
>> +     if (file_exists(git_path("CHERRY_PICK_HEAD"))) {
>> +             if (advice_resolve_conflict)
>> +                     die("You have not concluded your cherry-pick (CHERRY_PICK_HEAD exists).\n"
>> +                         "Please, commit your changes before you can merge.");
>> +             else
>> +                     die("You have not concluded your cherry-pick (CHERRY_PICK_HEAD exists).");
>> +     }
>
> Micronit: "Please, commit your changes before you can merge."
>
>  - We are not merging in this codepath to begin with;
>
>  - I'd suggest rephrasing this (together with "MERGE_HEAD" codepath) to
>   something like:
>
>        "Commit your changes first before retrying."

This hunk is from Jonathan, so I'd like him to address your comment as
well, but I think the current message is correct. This hunk is inside
cmd_merge and the user is about to start a merge. IOW:

$ git cherry-pick   # fails, leave behinds CHERRY_PICK_HEAD
 [... time passes ...]
$ git merge
You have not concluded your cherry-pick (CHERRY_PICK_HEAD exists).
Please, commit your changes before you can merge.

> Getting tired of seeing these five lines repeated over and over.  Perhaps
> it is time to introduce:

Okay. (Will roll in from Jonathan's later email.)

>> +     git cherry-pick --no-commit base &&
>> +
>> +     test_cmp_rev base CHERRY_PICK_HEAD
>
> If the next "git commit" would notice and use this information, that would
> introduce an unpleasant regression to one use case in my workflow, which
> is to pick and consolidate one or more small pieces made on a private
> "misc" branch, possibly with a bit of further work, into a new commit with
> a readable explanation that is unrelated to any of the original commits:
>
>        git cherry-pick --no-commit $some_commit
>        git cherry-pick --no-commit $another_commit ;# optional
>        edit ;# optional
>        git commit
>
> I'd prefer to see a way to tell cherry-pick not to leave CHERRY_PICK_HEAD
> behind when "cherry-pick --no-commit" results in a successful cherry-pick
> to avoid a backward incompatibility surprise.  Otherwise people need to
> retrain their fingers to say --reset-author when they run "git commit".

Okay. In that case, I think when using --no-commit, we shouldn't write
CHERRY_PICK_HEAD regardless of whether there is a conflict or not.

j.