Re: [PATCH v3 1/4] Introduce CHERRY_PICK_HEAD
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Feb 20, 2011, 02:29 UTC
- 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:
Show 26 quoted lines
> 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.)
Show 19 quoted lines
>> + 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.