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 -- 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