On Thu, Feb 17, 2011 at 3:01 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jay Soffian <jaysoffian@xxxxxxxxx> 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.
--
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