Re: [PATCH] sequencer: preserve commit messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano venit, vidit, dixit 26.02.2015 20:49:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]