Re: git mailinfo strips important context from patch subjects

On Sun, Jun 28, 2009 at 08:38:58PM +0100, Roger Leigh wrote:

In most of the projects I work on, the git commit message has
the affected subsystem or component in square brackets, such as

  [foo] change bar to baz

[...]

The [sbuild] prefix has been dropped from the Subject, so an
important bit of context about the patch has been lost.

It's a bit of a bug that you can't round trip from a git-format-patch
to import with git-am and then not be able to produce the exact same
patch set with git-format-patch again (assuming preparing and applying
to the same point, of course).

As an immediate solution, you probably want to use "-k" when generating
the patch (not to add the [PATCH] munging) and "-k" when reading the
patch via "git am" (which will avoid trying to strip any munging).

However:

Would it be possible to change the git-mailinfo logic to use a less
greedy pattern match so it leaves everything after
([PATCH( [0-9/])+])+ in the subject?  AFAICT this is cleanup_subject in
builtin-mailinfo.c?  Could this rather complex function not just do a
simple regex match which can also take care of stripping ([Rr]e:) ?

Yes, I think in the long run it makes sense to strip just the _first_
set of brackets. I don't think we want to be more specific than that in
the match, because we allow arbitrary cruft inside the brackets (like
"[RFC/PATCH]", etc). But if format-patch always puts exactly one set of
brackets, and am strips exactly one set, then that should retain your
subject in practice, even if it starts with [foo].

-Peff