Re: merge summaries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> writes:

> Steffen Prohaska <prohaska@xxxxxx> 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").



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux