"Shawn O. Pearce" [off-list ref] 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".
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
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.