[BUG] "git commit" after "cherry-pick -n" conflict clobbers .git/COMMIT_EDITMSG

[BUG] "git commit" after "cherry-pick -n" conflict clobbers .git/COMMIT_EDITMSG

[Yann Dirson]

(only tested with 1.7.10.x for now)

~/softs/linux$ echo foo > .git/COMMIT_EDITMSG
~/softs/linux$ git cherry-pick -n b55f3d92cd
error: could not apply b55f3d9... Linux 2.6.32.26
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
~/softs/linux$ cat .git/COMMIT_EDITMSG
foo

So far, so good.  But then "git commit" brings me the message from the
cherry-picked commit plus the list of conflicted files, and I can verify that
it is now the contents of .git/COMMIT_EDITMSG.

Surely the fact I passed "-n" should prevent cloberring the message, even in the
event of a conflict.  I suppose that would imply not creating .git/MERGE_MSG in that
case, but just removing it still causes .git/COMMIT_EDITMSG to be clobbered, this
time with nothing but the "git status"-derived comments.

-- 
Yann Dirson - Bertin Technologies

Re: [BUG] "git commit" after "cherry-pick -n" conflict clobbers .git/COMMIT_EDITMSG

[Junio C Hamano]

Yann Dirson <dirson@bertin.fr> writes:

> (only tested with 1.7.10.x for now)
>
> ~/softs/linux$ echo foo > .git/COMMIT_EDITMSG

Why are you mucking with such an internal implementation detail in
the first place?

> ~/softs/linux$ git cherry-pick -n b55f3d92cd
> error: could not apply b55f3d9... Linux 2.6.32.26
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add <paths>' or 'git rm <paths>'
> ~/softs/linux$ cat .git/COMMIT_EDITMSG
> foo
>
> So far, so good.  But then "git commit" brings me the message from the
> cherry-picked commit plus the list of conflicted files, and I can verify that
> it is now the contents of .git/COMMIT_EDITMSG.

You verified that "what" is now in .git/COMMIT_EDITMSG?  The commit
log message for you to edit to record the result of the cherry-pick?

If that is the case, what is the problem?

If anything you had in .git/COMMIT_EDITMSG before you started
"'cherry-pick -n', edit further to adjust, and then 'commit'"
sequence were to appear in the editor to edit the commit log,
it would be a bug, I would think.

Re: [BUG] "git commit" after "cherry-pick -n" conflict clobbers .git/COMMIT_EDITMSG

[dirson]

> > ~/softs/linux$ echo foo > .git/COMMIT_EDITMSG
>
> Why are you mucking with such an internal implementation detail in
> the first place?

I only tried to make it terse for the bugreport, I hit this while I
was resolving conflicts during a merge.  I aknowledge that using
"cherry-pick -n" to bring some contents to resolve a conflict is not
really nominal - my use case involves re-merging an updated "upstream"
branch, and bringing in fixups to the original merge.

> > ~/softs/linux$ git cherry-pick -n b55f3d92cd
> > error: could not apply b55f3d9... Linux 2.6.32.26
> > hint: after resolving the conflicts, mark the corrected paths
> > hint: with 'git add ' or 'git rm '
> > ~/softs/linux$ cat .git/COMMIT_EDITMSG
> > foo
> >
> > So far, so good. But then "git commit" brings me the message
> from the
> > cherry-picked commit plus the list of conflicted files, and I
> can verify that
> > it is now the contents of .git/COMMIT_EDITMSG.
>
> You verified that "what" is now in .git/COMMIT_EDITMSG? The commit
> log message for you to edit to record the result of the cherry-pick?

Precisely

> If that is the case, what is the problem?

I used "-n" precisely because I did not want to make a standalone
commit, and the message from the cherry-picked source has no value to
me.  If it had, I would instead have used cherry-pick without -n, and
amended the commit afterwards.

In the general case, I only ever use -n when I'm squashing changes
and similar tasks.  Are there use cases out there, where it makes
sense to keep that source message, when we don't want the commit to be
created right away ?


> If anything you had in .git/COMMIT_EDITMSG before you started
> "'cherry-pick -n', edit further to adjust, and then 'commit'"
> sequence were to appear in the editor to edit the commit log,
> it would be a bug, I would think.

Well, seems to depend on use case - I find it a bug when the merge message,
notably containing the list of conflicting files, gets clobbered.

Also, I have not checked how git gui reacts, but I would assume that
when carefully and iteratively composing a commit message from there,
which is IIRC managed using .git/COMMIT_EDITMSG, it would not be
desired to get this content clobbered the same way.

To me it looks like the problem is that the commit message in
preparation is not considered precious information, when there are at
least some cases where it indeed should be.  I'm not sure however how
that should be done:

* suddenly claiming it is precious (and require some form of -f to
  clobber it) when it was mostly not is likely to break a number of
  use cases
* looking at the context (are we resolving a merge or similar ?) to
  consider it precious is likely to miss some cases
* declaring a new official location (or API/command ?) to store
  considered-precious message being composed may bring its own lot of
  semantic difficulties