Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 8, 2007, 01:35 UTC
Message-ID: <20070508013532.GA11311@spearce.org>
In-Reply-To: <7vps5efnv8.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 11 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > What about this change instead?  We make cherry-pick/revert
> > use the same temporary file as merge, which is under .git/
> > (something Alex mentioned he wanted).  I think the use of ".msg"
> > in cherry-pick/revert has always just been a bug, and not a feature,
> > so I'm really not against changing things around like this.
> 
> While I would not say this is not an improvement, this makes
> MERGE_MSG even less about merges and pushes us away from a
> sensible "git whatnow".

 
I think that ship has already sailed.  Look at builtin-revert.c
on:

    333         const char *target = git_path("MERGE_MSG");

We're already using MERGE_MSG to prep the message for a conflicted cherry-pick or revert that the user needs to resolve by hand. I think we do the same thing in git-rebase, don't we?

Gerrit's patch to try and use COMMIT_MSG feels wrong to me, as git-commit overwrites that file with what it gets from its "input".

I agree my patch steps us further from a "git whatnow", but we're already in deep with MERGE_MSG. We might as well keep that existing convention that it can be used to prep the commit message for the next git-commit invocation, and record other data somehow for the "git whatnow" case.

-- 
Shawn.