Re: [PATCH] sequencer: preserve commit messages
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Feb 27, 2015, 15:31 UTC
- Message-ID
- <54F08DE8.3080907@drmicha.warpmail.net>
- In-Reply-To
- <xmqq61aomp1d.fsf@gitster.dls.corp.google.com>
Junio C Hamano venit, vidit, dixit 26.02.2015 20:49:
Show 48 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes: > >> Hmm. With "--edit", current config being in effect should be expected, >> right? So how about: >> >> In case of no conflict: force cleanup=verbatim unless --edit is used? > > Perhaps something like that. > > Stepping back a bit and imagine a world where the sole purpose of > cherry-pick were to recreate the original commit as faithfully as > possible. The commit log message would not be cleaned up in such > a case by default, and the users need cherrypick.cleanup setting > if they do not like that default. > > The implementation of cherry-pick that does not spawn the editor > in that world would look like this: > > - read the cleanup mode from cherrypick.cleanup config; if there > is none, read the cleanup mode from commit.cleanup config; if > neither is defined, then use 'verbatim' as the default; > > - invoke "commit --cleanup=" + that mode from the command line > to force the mode chosen by the above. > > Thanks to the falling back to commit.cleanup, the above logic would > be usable even before we invent cherrypick.cleanup configuration, > i.e. in today's world. If there is no commit.cleanup defined by the > user, the above logic would still use 'verbatim' as the default for > 'cherry-pick', while using the 'default' for 'commit'. > > When cherry-pick invokes the editor, then the first part would be > different. So my conclusion would be something like: > > #if IN_THE_FUTURE > if (config_exists(cherrypick.cleanup)) > mode = config_value(cherrypick.cleanup); > else > #endif > if (config_exists(commit.cleanup)) > mode = config_value(commit.cleanup); > else > mode = editing ? 'verbatim' : 'default'; > > invoke "commit --cleanup=" + mode; > > perhaps? >
Without any config being set the result is certainly what I'm after.
What I'm still wondering about is the case without --edit but with commit.cleanup: It seems to me that "git commit" being involved in a conflict-less cherry-pick is solely an implemention detail (and it could be done differently). Applying commit.* in this situation is a total surpise to the normal user, isn't it? I mean, again, what's the difference to rebase from a user perspective?
Michael