Re: [PATCH v3 1/4] Introduce CHERRY_PICK_HEAD

On Thu, Feb 17, 2011 at 3:01 PM, Junio C Hamano [off-list ref] wrote:

Jay Soffian [off-list ref] writes:

quoted

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

quoted

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