Re: [PATCH] fmt-merge-msg: show those involved in a merged series

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

Jonathan Nieder <jrnieder@gmail.com> writes:

> ....  As a person reading the history, I admit I don't like it.
> I enjoyed being able to get a simple overview at a higher level of
> what has been happening in "pu" with "git log --merges junio/pu" or
> "git log --first-parent junio/pu", and these extra lines before and
> adjacent to the "* name of topic:" header interfere with that.

I'd hold making that judgement for a several weeks until my eyes get
used to if I were you. I've seen that people (including myself)
react really badly to _any_ change and make loud noises (including
"we will never get used to this updated output, it is horrible!"),
and then eventually get used to it as if nothing happened, and that
happened often enough recently.

In any case, if you only look at "git log --first-parent" output and
search for your own topic, it of course is useless to see your name
there, as you already know.

> By contrast, the
> ...
> descriptions in Linus's repo are very pleasant.

When you compare Linus's history and my history between master..pu,
you are literally comparing apples and oranges.

The merges between master..pu are made several times a day, with a
series of mechanical "merge --no-edit" process and automated tree
tweaking (including but not limited to rerere).  The purpose of
these merges is primarily to reduce the risk of mismerges to master
(and next to a lessor degree), especially when one topic among many
that have been cooking between master..pu gets closer to graduation.
By shuffling the order of topics that are merged between master..pu
so that topics close to graduation come earlier in the fully rebuilt
pu, a mid-point in master..pu is verified to exactly match the tree
of next (otherwise you may have spotted a mismerge to next, and I
did spot a few mismerges to next this way). This also allows earlier
parts of the master..pu to be tested individually.

The purpose of these merges is _not_ about describing what the side
branches are about. Unlike Linus's lieutenants' "for-linus" branch
names, the branch names are often enough to describe that they are.

On the other hand, the merges on Linus's tree are etched in stone,
and he has every incentive to record what happened in the side
branch for the _last_ time with carefully chosen words.

Having said that, I tweaked the automated rebuilding procedure a bit
today, and made it annotate these merges with snippets from the
branch description in the "What's cooking" document, so the commits
on master..pu are hopefully "very pleasant"ly annotated.  This not
only prettifies the merges between master..pu, but more importantly,
would save effort to explain the merges when a topic finally hits
master. If I have a good description in "What's cooking", I can then
reuse it in these merges and also in the release notes.

The update to the rebuild procedure is not published yet. I'll be
playing with it for a few days before publishing the changes.