Re: merge summaries

Junio C Hamano [off-list ref] writes:

Steffen Prohaska [off-list ref] writes:

quoted

What is so wrong if merge summaries of pulls from you were committed
to topic branches. Later when you pull such branches the summaries
shouldn't be a problem. A short-log of the topic branch wouldn't
contain the summaries.

Probably I do not fully understand what "the wrong way around" means.

I think you understand it very well.

As long as you stay as a "pull-only" person, and will never ask
the upstream to pull back from you, what first parent log would
show would make perfectly good sense.  However, once a pull from
you by the upstream happens, the resulting history would get the
summary in the merge you did, which is totally unwanted --- the
upstream already had those summarized commits long time ago in
its history.

Having said that.

The criteria to decide "wanted vs unwanted" all boil down to
essentially the question of who "owns" the history.  Although
Linus often says that the point of distributed development is
that nobody is special, at the end of day, once you asked the
"upstream" to pull from you, your history becomes part of HIS
history, and at that point, when HE browses the history (which
he now thinks as HIS history), the summary shows the summary the
wrong way.  So in that sense, merge.summary is going against the
philosophy of distributedness.

The summary message is useful in a very short term (i.e. while
it is still near the tip of the branch and running "git log"),
but I think JBF is correct to point out that it is showing a
shortcoming of our history browsing tools.  The information
recorded there can easily be reproduced on the fly.  Whenever
you see a merge commit, you can choose one parent to base your
view of the history upon (typically the first parent), and
summarize commits that are reachable from other parents but not
from that parent (e.g. for a typical two-parent merge, you would
run "git short-log $commit^1..$commit^2").