Junio C Hamano <junkio@xxxxxxx> writes: > Steffen Prohaska <prohaska@xxxxxx> writes: > >> But this is true not only for the upstream master but for every branch. >> The first-parent-path of any commit documents (at least in summaries) >> which features were introduced to the branch at which place. If a >> topic pulls from upstream, features already available in the upstream >> are introduced to the topic at this time. Why not summarize this? Because it does not matter from the overall picture at that point. In an earlier message I said that the summary is useful in a very short term -- the summary messages are useful while the person who did the merge (or somebody who is simply following him) is looking at near the tip of the branch, but when you are later viewing the older parts of the history from 10,000 feet above, the distinction between what were pulled into the local branch of the person who made the merge vs what the person already had on the branch when he made the merge becomes more or less irrelevant. The end result is that the project now got the fruits of labor that happened on both sides. > Strictly speaking, it is not even correct with the upstream > master. I believe even my own 'maint' has fast forward merge > that I pulled from other people, and that part of the history if > you follow first-parent, you would not be following the "project's" > history (if there is such a thing, and if you are equating it > with "JC's view of the history"). Regrettably, I have to say that --first-parent is, although it is often a useful way to get an approximation, a bad option that tends to instill a wrong mental model to people new to git. In git, unlike CVS and SVN (I do not know now Monotone, Mercurial and BitKeeper's branches work with this respect), branches in git do not have their "own" identity in global history that is recorded in the commit ancestry graph. The only way you can ask "how did this branch come about to this state?" is to look at your own reflog, and that is strictly a local thing (i.e. the history as you observed it). Even when you are "the upstream maintainer" [*1*], there are cases where you pushed your tips out to the open, other people built their work on top of it while you were not adding anything to your tree, and you end up pulling from them. Such a pull will result in a fast-forward merge, and that is rightly so. They did all the work, and the collective history of the project during that time literally followed what the other person did, not the "upstream maintainer". However, from the point of view of somebody who is following the upstream maintainer's tree, what he would observe is that at one point of the time the tip of the tree was the last commit the upstream maintainer pushed out (which became the base of the other person's work), and then the next time you look at the tree there are bunch of commits by the other person, appearing all at once even though there is no "real" merge commit that summarizes the work done on the "side branch". Which some of the readers might feel a bit confusing and inconsistent, but that is really the correct interpretation of the history. The reason I feel --first-parent helps this confusion is that people would think it would be consistent if we do not allow fast-forward merges and instead always forced a real merge in such a case (then you would consistently get the merge summary). In other words, the first parent is not inherently special -- and people should view history that way, but --first-parent and merge.summary give this false impression that it is somehow special. Anyhow, enough rambling for a day. Now I have two releases to do tonight ;-) [Footnote] *1* In git, strictly speaking, there is no up or down, but as a social convention, I get updates from Shawn, Paulus, Bruce and few other people via pull, and it would not be too incorrect to say I'm more upstream than they are, and all others are more downstream. - 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
