From: Shawn O. Pearce Date: Tue, 08 May 2007 01:35:32 GMT Subject: Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion. Message-ID: <20070508013532.GA11311@spearce.org> In-Reply-To: <7vps5efnv8.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > "Shawn O. Pearce" 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.