On Thu, Feb 28, 2019 at 11:02:11AM +0100, Max Filenko wrote:
> Subject: [PATCH] :::: four colons prepended
> [...]
> There will be no colons in the beginning of a commit message if I apply
> this patch:
>
> $ git am 0001-four-colons-prepended.patch
> Applying: four colons prepended
I suspect this has to do with the sanitization that happens as part of
removing "[PATCH]". Note that if you use "-k" (to preserve the subject)
it doesn't happen, though of course you also get "[PATCH]" then.
If you want to pass the subject lines through verbatim, use "-k" with
both format-patch and git-am.
> I was able to trace this down to <builtin/am.c>. It seems like there are
> no colons already in the `state->msg' which to my understanding is being
> filled by `read_commit_msg()' function. I would really appreciate a hand
> on debugging it further.
It's probably easier to debug with git-mailinfo, which has the same
behavior:
$ git mailinfo msg patch <0001-four-colons-prepended.patch
Author: Jeff King
Email: peff@xxxxxxxx
Subject: four colons prepended
Date: Thu, 28 Feb 2019 06:12:50 -0500
and is based on the same routines.
The contents are preserved until we end up in mailinfo.c's
cleanup_subject(). And there leading colons are explicitly removed:
case ' ': case '\t': case ':':
strbuf_remove(subject, at, 1);
continue;
That behavior goes all the way back to 2744b2344d (Start of early patch
applicator tools for git., 2005-04-11), when Git was only 4 days old.
Since it also handles cruft like "Re:", I suspect the goal there was I
suspect the goal there was to remove cruft like "Re::::" or "Re: :"
which sometimes happens. I don't know if anybody would complain if we
were more careful about leaving lone colons that weren't part of a "Re"
chain.
-Peff
