Re: merge summaries

From: Junio C Hamano <junkio@cox.net>
Date: May 19, 2007, 20:20 UTC
Message-ID: <7vy7jkva41.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vy7jkwr96.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 18 quoted lines

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> 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").