Re: [PATCH/RFC] fmt-merge-msg: add a blank line after people info

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Turns out my reaction is pretty much the same as before.  I still like
> the idea and still am distracted by the spacing.  After the small
> patch below, the log seems peaceful again and I am totally fine with
> it.
>
> 	Merge branch for-upstream of git://git.example.com/subsystem
>
> 	By Fred the Clown
>
> 	* for-upstream: (51 commits)
> 	  foo: bar baz

Two possible factors that may not be visible in the above example are

 (1) hand-written description of the merge itself by the integrator; and
 (2) octopus merges.

With both of these elements, with a blank line after the submaintainer and
the contributor attribution, a sample log output would look like this:

        Merge branches fix-foo and fix-bar of git://git.example.com/subsystem

        Two last minute fixes from Fred, so that we won't have to
        scramble and tell people to upgrade again immediately after
        the upcoming release.

        By Fred the Clown

        * fix-foo: (2 commits)
          foo: fix forboz
          foo: reindent

        By Fred the Clown

        * fix-bar: (1 commit)
          bar: fix nitfol

The attribution to the submaintainer and contributors, the name of the
branch merged, and the list of the individual changes form a single unit
of information "What was done for us by whom".  At least to me, the above
is easier to see without the additional blank line; the even-spacing
before and after the attribution line makes it harder to see where the
boundary between "description by the integrator on the merge" and
"information on the work that was done on the first branch that was
merged" is (and the boundary between the first and the second work, if in
an octopus).

We could add another blank line before the "credit" line.  We would have
two blank lines that separates the integrator comment and the per-branch
block, and also have two blank lines between the per-branch blocks, making
it easy again to see where the boundaries are.

But I do not know if it is an improvement from the current output before
your patch, or if it is just wasting vertical space.