On 12/02/2015 01:58 AM, Jeff King wrote:
> On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote:
> 
>> Yes, it looks like the `--keep-non-patch` option works around this.
>>
>> However, shouldn't that be the default behaviour?
>> I mean, what is the point in stripping stuff that is not proven to be inserted by `git` itself?
>> That's not what I expect a tool to do which I trust.
> 
> The "[]" convention is a microformat used by Linux kernel folks. So it's
> not "whoops, we are stripping stuff not added by git". It is respecting
> a microformat used by the tool's authors.
> 
> That being said, if we were choosing a default from scratch today, it
> might go the other way. But we aren't, and we have to deal with the
> burden of breaking existing scripts by flipping it.
> 
> -Peff

Ok, I think I understand the reason for this behavior now.
However, I still believe that the `git format-patch`/`git am` combo
should retain the original commit messages by default.

As such, I would like to ask whether it would be possible/sensible
to somehow escape square brackets, or mark the beginning
of the original commit message in the `git format-patch` output?
This would allow `git am` to reproduce the exact commit message by default
without breaking the "[]" convention.


For example, I could imagine to use this behavior:

  * `git format-patch` produces a message of the format "[PATCH ...]: original commit message".

  * `git am` strips the longest prefix that consists entirely of bracketed stuff
    and ends with the string "]: ". If that terminator is not found -> old behavior.

  * Users could insert any "[FOO]" strings they like before the ":",
    which would still be stripped from the commit message by `git am`.

Of course, any such change would not be without pitfalls. With the rule above,
we would get ": " prepended to commit messages if a patch is created with a `git` version
that has the change, and applied with an older version that does not know about the terminator.


What do you guys think? Is there anything I missed?


Cheers,
Nathanael


-- 
Please be aware that the enemies of your civil rights and your freedom
are on CC of all unencrypted communication. Protect yourself.