Re: [PATCH] sequencer: preserve commit messages

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

 



Junio C Hamano venit, vidit, dixit 24.02.2015 19:29:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> 
>>> Hmm, wouldn't it introduce a grave regression for users who
>>> explicitly ask to clean crufty messages up (by setting their own
>>> commit.cleanup configuration) if you unconditionally force
>>> "--cleanup=verbatim" here?
>>>
>>
>> That's what I meant by possible side-effects below.
>> ...
>> But git cherry-pick without conflict should no re-cleanup the commit
>> message either, should it?
> 
> Hmm, but if it does not, wouldn't that countermand the wish of the
> user who explicitly asked to clean crufty messages up by setting
> their own commit.cleanup configuration?
> 

Note that "verbatim" is not the default - we cleanup commits even
without being asked to. And this makes sense for "git commit", of course.

I myself certainly expected "git cherry-pick" to transfer a commit as
verbatim as possible. "git rebase" preserves the commit message (at
least more than cherry-pick). What's the difference between them?
Technically the difference between commit-tree and commit, sure, but for
the user?

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]