Re: A possible fmt-merge-msg update?

From: Jeff King <peff@peff.net>
Date: Mar 6, 2012, 07:59 UTC
Message-ID: <20120306075940.GA21199@sigill.intra.peff.net>
In-Reply-To: <CA+55aFw-sS_p7JXNXbSbpiwh9_bZhSrTtC3is4NtLa_n9Hzk5A@mail.gmail.com>

On Mon, Mar 05, 2012 at 12:33:42PM -0800, Linus Torvalds wrote:

Show 12 quoted lines

> On Mon, Mar 5, 2012 at 11:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > The attached would give me:
> 
> So this isn't interesting to me.
> 
> Authorship is less relevant than submaintainership. So I'm more
> interested in *committer* information than authorship information.
> 
> Of course, since you do it in branches that you maintain, to you
> committer information is pointless. But I pull from submaintainers,
> and then it really is the committer part that is way more relevant.

If you're interested in the sub-maintainer, and the sub-maintainer is who you pulled from, then isn't the right solution to better annotate the source of the pull? For the kernel workflow, that often comes in the form of pulled tags; would providing the tagger in that case be helpful? (it's often already included in the commit template via the commented-out GPG output, but there might be many UIDs attached to a given GPG key).

That wouldn't help the git.git workflow, of course, but I think you are talking about two fundamentally different things. The kernel thing is about annotating the source of the pull. The git.git thing (and Junio's patch) is about summarizing the contents of the branch not just with the subject lines, but also with the author's names[1].

But looking through some recent kernel merges, the useful new thing in the message doesn't seem to me to be the _who_, but rather the _what_. For example, from f3969bf7:

  Pull perf fixes from Ingo Molnar:
   "It contains three cherry-picked fixes from perf/core, which turned out
    to be more urgent than we originally thought."

So rather than focus on the identity of the sub-maintainer, perhaps a more useful thing is to make it easier to pass information from a pull request into the resulting merge message. We already have "git am" for regular patches, and it relies on a few easy-to-generate microformats, so it's natural to use with "git format-patch", your own custom script, or even by hand. Could we do the same thing and have a "git apply-pull-request" (or something with a less horrible name)?

Ingo's original message looked like:

    From: Ingo Molnar <mingo@elte.hu>
    Subject: [GIT PULL] perf fixes

    Linus,

    Please pull the latest perf-urgent-for-linus git tree from:

       git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus

       HEAD: b7c924274c456499264d1cfa3d44063bb11eb5db Merge tag 'perf-urgent-for-mingo' of
    git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

    It contains three cherry-picked fixes from perf/core, which 
    turned out to be more urgent than we originally thought.

     Thanks,

            Ingo

If this were instead formatted as:

  From: Ingo Molnar <mingo@elte.hu>
  Subject: [GIT PULL] perf fixes

  Here are three cherry-picked fixes from perf/core, which turned out to
  be more urgent than we originally thought.

  ---
    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus

    HEAD: b7c924274c456499264d1cfa3d44063bb11eb5db Merge tag 'perf-urgent-for-mingo'
      of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

we could trivially convert that into the same commit message you ended up writing. The format is simple enough that people who aren't running it through a script can read and write it, and we retain the single line with the repo and ref name for those who want to just cut and paste.

-Peff