{"thread":{"id":"8198","subject":"merge summaries","startedAt":"2007-05-18T05:44:53Z","lastAt":"2007-05-20T20:38:23Z","messageCount":18,"participants":["Steffen Prohaska","Linus Torvalds","Junio C Hamano","J. Bruce Fields","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42447","messageId":"25A3C618-8D12-42A8-9478-D3A4E7633CE7@zib.de","threadId":"8198","inReplyTo":null,"subject":"merge summaries","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-18T05:44:53Z","receivedAt":"2007-05-18T05:44:53Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"It took me some time to figure out how to get summaries of the merged \nbranch into merge messages. Finally I recognized that I simply need \nto set\n\n\tgit-config merge.summary true\n\n\nI have two questions:\n1) Why isn't 'true' the default setting? The two probably most \nprominent git repositories, git and kernel, both use merge summaries. \nAfter some time working with git I started to wonder, how these guys \ncreate the nicely formatted branch summaries. If merge summaries are \napparently best practice, why are they missing in my local merges?\n\n2) Why does git-merge have a switch '--no-summary' to switch \nsummaries off, but doesn't have a switch '--summary' to switch them \non? After some time of searching for the solution I started to \nbelieve that Linus and Junio might use some shell magic to create \ntheir merge messages, which they pipe to git-merge's -m switch. This \ninconsistency made finding the simple solution even harder.\n\n- Steffen\n"},{"id":"42501","messageId":"alpine.LFD.0.98.0705181130580.3890@woody.linux-foundation.org","threadId":"8198","inReplyTo":"25A3C618-8D12-42A8-9478-D3A4E7633CE7@zib.de","subject":"Re: merge summaries","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-18T18:33:57Z","receivedAt":"2007-05-18T18:33:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 May 2007, Steffen Prohaska wrote:\n>\n> It took me some time to figure out how to get summaries of the merged branch\n> into merge messages. Finally I recognized that I simply need to set\n> \n> \tgit-config merge.summary true\n\nYes.\n\n> I have two questions:\n> 1) Why isn't 'true' the default setting? The two probably most prominent git\n> repositories, git and kernel, both use merge summaries.\n\nThink about _who_ uses it for those two prominent repositories for a while.\n\n[ pause, ponder here ]\n\nIn other words, \"merge.summary\" should be true ONLY FOR TOP-LEVEL \nMAINTAINERS.\n\nMaking it true for anybody else is almost always a bug. Yes, I and Junio \nhave it enabled, but pretty much nobody else should, because if they pull \nfrom me or Junio in order to merge, their merge summaries would be exactly \nthe wrong way around!\n\n> 2) Why does git-merge have a switch '--no-summary' to switch summaries off,\n> but doesn't have a switch '--summary' to switch them on?\n\nProbably because \"normal users\" should never use summaries in the first \nplace, so it's just not been an issue.\n\n\t\tLinus\n"},{"id":"42505","messageId":"7vodki55px.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"alpine.LFD.0.98.0705181130580.3890@woody.linux-foundation.org","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T18:47:38Z","receivedAt":"2007-05-18T18:47:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> I have two questions:\n>> 1) Why isn't 'true' the default setting? The two probably most prominent git\n>> repositories, git and kernel, both use merge summaries.\n>\n> Think about _who_ uses it for those two prominent repositories for a while.\n>\n> [ pause, ponder here ]\n>\n> In other words, \"merge.summary\" should be true ONLY FOR TOP-LEVEL \n> MAINTAINERS.\n>\n> Making it true for anybody else is almost always a bug. Yes, I and Junio \n> have it enabled, but pretty much nobody else should, because if they pull \n> from me or Junio in order to merge, their merge summaries would be exactly \n> the wrong way around!\n\nThis does not necessarily mean that your lieutenants should not\nuse merge.summary when they pull from other trees (or inside\ntheir own repository to merge in the topics). They need to\nhowever disable it with --no-summary when they pull from you\nwhen they choose to merge instead of rebase to adjust to the\nupdated infrastructure in your tree.\n"},{"id":"42508","messageId":"alpine.LFD.0.98.0705181206051.3890@woody.linux-foundation.org","threadId":"8198","inReplyTo":"7vodki55px.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge summaries","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-18T19:13:02Z","receivedAt":"2007-05-18T19:13:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 May 2007, Junio C Hamano wrote:\n> \n> This does not necessarily mean that your lieutenants should not\n> use merge.summary when they pull from other trees (or inside\n> their own repository to merge in the topics). They need to\n> however disable it with --no-summary when they pull from you\n> when they choose to merge instead of rebase to adjust to the\n> updated infrastructure in your tree.\n\nYes, the problem is that people *will* get it wrong, so right now I'd \ndiscourage people from even trying to enable merge summaries unless they \nare the top-level maintainer.\n\nOf course, we could have some heuristics to make it possibly work well \nenough in practice that we could make it useful to more people:\n\n - take the \"merge.summary\" field from the \"remote\" description for any \n shorthand cases, always defaulting to \"off\" (regardless of what the \n \"merge.summary\" config value is)\n\n End result: \"git pull origin\" would never generate a merge summary, \n unless somebody explicitly sets\n\n\t[remote \"origin\"]\n\t\tmergesummary = true\n\n - use the \"merge.summary\" flag only for explicitly named remotes (and \n possibly add \"--summary\" so that people can choose to never do it by \n default, but do it explicitly for when they pull from a sublieutenant)\n\nHmm?\n\n\t\tLinus\n"},{"id":"42535","messageId":"20070518215603.GS15393@fieldses.org","threadId":"8198","inReplyTo":"alpine.LFD.0.98.0705181206051.3890@woody.linux-foundation.org","subject":"Re: merge summaries","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-18T21:56:03Z","receivedAt":"2007-05-18T21:56:03Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, May 18, 2007 at 12:13:02PM -0700, Linus Torvalds wrote:\n> \n> On Fri, 18 May 2007, Junio C Hamano wrote:\n> > \n> > This does not necessarily mean that your lieutenants should not\n> > use merge.summary when they pull from other trees (or inside\n> > their own repository to merge in the topics). They need to\n> > however disable it with --no-summary when they pull from you\n> > when they choose to merge instead of rebase to adjust to the\n> > updated infrastructure in your tree.\n> \n> Yes, the problem is that people *will* get it wrong, so right now I'd \n> discourage people from even trying to enable merge summaries unless they \n> are the top-level maintainer.\n\nI never quite understood what they're for--do they add any information\nnot already available in the history? If not, and if people still find\nthem helpful anyway, then I dunno, it looks like a sign of some sort of\nfailure of our history display tools.\n\n--b.\n"},{"id":"42556","messageId":"alpine.LFD.0.98.0705181611520.3890@woody.linux-foundation.org","threadId":"8198","inReplyTo":"20070518215603.GS15393@fieldses.org","subject":"Re: merge summaries","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-18T23:12:26Z","receivedAt":"2007-05-18T23:12:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 May 2007, J. Bruce Fields wrote:\n> \n> I never quite understood what they're for--do they add any information\n> not already available in the history? If not, and if people still find\n> them helpful anyway, then I dunno, it looks like a sign of some sort of\n> failure of our history display tools.\n\nI don't think they add much in the case of a graphical viewer, but for \n\"git log\", it does make it look nicer..\n\n\t\tLinus\n"},{"id":"42558","messageId":"7vhcq94sgi.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"alpine.LFD.0.98.0705181611520.3890@woody.linux-foundation.org","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T23:34:05Z","receivedAt":"2007-05-18T23:34:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 18 May 2007, J. Bruce Fields wrote:\n>> \n>> I never quite understood what they're for--do they add any information\n>> not already available in the history? If not, and if people still find\n>> them helpful anyway, then I dunno, it looks like a sign of some sort of\n>> failure of our history display tools.\n>\n> I don't think they add much in the case of a graphical viewer, but for \n> \"git log\", it does make it look nicer..\n\nEspecially if you do \"git log --first-parent\" ;-).\n"},{"id":"42607","messageId":"73A1C4C5-50E9-4844-85F8-00D99682B6D4@zib.de","threadId":"8198","inReplyTo":"7vodki55px.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge summaries","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-19T09:35:56Z","receivedAt":"2007-05-19T09:35:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn May 18, 2007, at 8:47 PM, Junio C Hamano wrote:\n\n>> Think about _who_ uses it for those two prominent repositories for \n>> a while.\n>>\n>> [ pause, ponder here ]\n>>\n>> In other words, \"merge.summary\" should be true ONLY FOR TOP-LEVEL\n>> MAINTAINERS.\n>>\n>> Making it true for anybody else is almost always a bug. Yes, I and \n>> Junio\n>> have it enabled, but pretty much nobody else should, because if \n>> they pull\n>> from me or Junio in order to merge, their merge summaries would be \n>> exactly\n>> the wrong way around!\n>\n> This does not necessarily mean that your lieutenants should not\n> use merge.summary when they pull from other trees (or inside\n> their own repository to merge in the topics). They need to\n> however disable it with --no-summary when they pull from you\n> when they choose to merge instead of rebase to adjust to the\n> updated infrastructure in your tree.\n\n[ ... pondering ... ]\n\nApparently parents of merge commits are not fully equal and summaries\ncan help to browse the history of a branch. If summaries are enabled\n\"git log --first-parent\" gives hints to all changes at least in\nshort-log form. Changes along the first-parent-path to the initial\ncommit are listed in full. All changes that were merged in are\nlisted in the summaries of the merge. This seems to be a useful feature.\n\nBut isn't this true for any branch and any merge. If someone pulls from\nyou or Junio and runs \"git log --first-parent\" why shouldn't he see\na summary of the changes that were pulled? At that point his branch's\nfirst-parent-path to the initial commit would not touch the changes\npulled from you. So the summary could help.\n\nWhat is so wrong if merge summaries of pulls from you were committed\nto topic branches. Later when you pull such branches the summaries\nshouldn't be a problem. A short-log of the topic branch wouldn't\ncontain the summaries.\n\nProbably I do not fully understand what \"the wrong way around\" means.\n\n- Steffen\n"},{"id":"42640","messageId":"7vy7jkwr96.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"73A1C4C5-50E9-4844-85F8-00D99682B6D4@zib.de","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-19T19:24:53Z","receivedAt":"2007-05-19T19:24:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> What is so wrong if merge summaries of pulls from you were committed\n> to topic branches. Later when you pull such branches the summaries\n> shouldn't be a problem. A short-log of the topic branch wouldn't\n> contain the summaries.\n>\n> Probably I do not fully understand what \"the wrong way around\" means.\n\nI think you understand it very well.\n\nAs long as you stay as a \"pull-only\" person, and will never ask\nthe upstream to pull back from you, what first parent log would\nshow would make perfectly good sense. However, once a pull from\nyou by the upstream happens, the resulting history would get the\nsummary in the merge you did, which is totally unwanted --- the\nupstream already had those summarized commits long time ago in\nits history.\n"},{"id":"42645","messageId":"7vy7jkva41.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"7vy7jkwr96.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-19T20:20:30Z","receivedAt":"2007-05-19T20:20:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Steffen Prohaska writes:\n>\n>> What is so wrong if merge summaries of pulls from you were committed\n>> to topic branches. Later when you pull such branches the summaries\n>> shouldn't be a problem. A short-log of the topic branch wouldn't\n>> contain the summaries.\n>>\n>> Probably I do not fully understand what \"the wrong way around\" means.\n>\n> I think you understand it very well.\n>\n> As long as you stay as a \"pull-only\" person, and will never ask\n> the upstream to pull back from you, what first parent log would\n> show would make perfectly good sense. However, once a pull from\n> you by the upstream happens, the resulting history would get the\n> summary in the merge you did, which is totally unwanted --- the\n> upstream already had those summarized commits long time ago in\n> its history.\n\nHaving said that.\n\nThe criteria to decide \"wanted vs unwanted\" all boil down to\nessentially the question of who \"owns\" the history. Although\nLinus often says that the point of distributed development is\nthat nobody is special, at the end of day, once you asked the\n\"upstream\" to pull from you, your history becomes part of HIS\nhistory, and at that point, when HE browses the history (which\nhe now thinks as HIS history), the summary shows the summary the\nwrong way. So in that sense, merge.summary is going against the\nphilosophy of distributedness.\n\nThe summary message is useful in a very short term (i.e. while\nit is still near the tip of the branch and running \"git log\"),\nbut I think JBF is correct to point out that it is showing a\nshortcoming of our history browsing tools. The information\nrecorded there can easily be reproduced on the fly. Whenever\nyou see a merge commit, you can choose one parent to base your\nview of the history upon (typically the first parent), and\nsummarize commits that are reachable from other parents but not\nfrom that parent (e.g. for a typical two-parent merge, you would\nrun \"git short-log $commit^1..$commit^2\").\n"},{"id":"42672","messageId":"0E590255-A3F4-4D36-B798-80364ACD0D06@zib.de","threadId":"8198","inReplyTo":"7vy7jkva41.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge summaries","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-20T08:17:01Z","receivedAt":"2007-05-20T08:17:01Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn May 19, 2007, at 10:20 PM, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n>> As long as you stay as a \"pull-only\" person, and will never ask\n>> the upstream to pull back from you, what first parent log would\n>> show would make perfectly good sense. However, once a pull from\n>> you by the upstream happens, the resulting history would get the\n>> summary in the merge you did, which is totally unwanted --- the\n>> upstream already had those summarized commits long time ago in\n>> its history.\n\nWhy would the summary of the upstream-to-topic-merge be so harmful?\nIt would not change the summary message of a pull from topic back to\nthe upstream. Af far as I can see, merge commits do not contribute\nto a summary message. However, when browsing the full log the summary\nmight be distracting because a single commit may be listed at\nvarious places, although it was already in the upstream. This is\nkind of ugly. ...\n\n\n> The criteria to decide \"wanted vs unwanted\" all boil down to\n> essentially the question of who \"owns\" the history. Although\n> Linus often says that the point of distributed development is\n> that nobody is special, at the end of day, once you asked the\n> \"upstream\" to pull from you, your history becomes part of HIS\n> history, and at that point, when HE browses the history (which\n> he now thinks as HIS history), the summary shows the summary the\n> wrong way. So in that sense, merge.summary is going against the\n> philosophy of distributedness.\n\n... I'd say you only \"own\" the history of a branch along its\nfirst-parent-path to the initial commit. This is what you control\neither by directly committing to the branch or by pulling other\nbranches.\n\nIsn't the history along the first parents especially important because\nit documents the functionality of the project? If I want to say \nsomething\nabout git at a certain point in time, I'd talk about master of the \nofficial\ngit repository. \"git log --first-parent\" in some sense completely\ndescribes the history of git. At merges at least a summary of features\npulled from topic branches is given.\n\nBut this is true not only for the upstream master but for every branch.\nThe first-parent-path of any commit documents (at least in summaries)\nwhich features were introduced to the branch at which place. If a\ntopic pulls from upstream, features already available in the upstream\nare introduced to the topic at this time. Why not summarize this?\n\n\n> The summary message is useful in a very short term (i.e. while\n> it is still near the tip of the branch and running \"git log\"),\n> but I think JBF is correct to point out that it is showing a\n> shortcoming of our history browsing tools. The information\n> recorded there can easily be reproduced on the fly. Whenever\n> you see a merge commit, you can choose one parent to base your\n> view of the history upon (typically the first parent), and\n> summarize commits that are reachable from other parents but not\n> from that parent (e.g. for a typical two-parent merge, you would\n> run \"git short-log $commit^1..$commit^2\").\n\nI find the summary messages quite useful when browsing merges. The \nsummary\nallows to quickly locate the branch that was merged at that point. \nYou just\nlook at the list of summaries and locate the mentioned commits in gitk.\n\nMinimal merge messages like \"Merge branch 'maint' of URL into maint\" are\nmuch harder to understand. The branches mentioned in the message do \nno longer\nhave any meaning. They either ceased to exist or advanced to \nsomewhere else.\nThe URL typically means nothing to me, although it may have meant a \nlot to\nthe one who pulled at the time of the pull. Such minimal messages do\nnot help browsing history.\n\nIt would probably be more useful to name the merged branch by the \nsummary\nof its head at the time of the merge. For example\n\"Merge branch 'user-manual: reorganize public git repo discussion'\"\nwould give more hints where to continue browsing than\n\"Merge branch 'maint' of URL into maint\".\n\n- Steffen\n"},{"id":"42673","messageId":"7vwsz3rjb6.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"0E590255-A3F4-4D36-B798-80364ACD0D06@zib.de","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-20T08:27:41Z","receivedAt":"2007-05-20T08:27:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> But this is true not only for the upstream master but for every branch.\n> The first-parent-path of any commit documents (at least in summaries)\n> which features were introduced to the branch at which place. If a\n> topic pulls from upstream, features already available in the upstream\n> are introduced to the topic at this time. Why not summarize this?\n\nStrictly speaking, it is not even correct with the upstream\nmaster. I believe even my own 'maint' has fast forward merge\nthat I pulled from other people, and that part of the history if\nyou follow first-parent, you would not be following the \"project's\"\nhistory (if there is such a thing, and if you are equating it\nwith \"JC's view of the history\").\n"},{"id":"42674","messageId":"7vveenq2ws.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"7vwsz3rjb6.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge summaries","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-20T09:07:15Z","receivedAt":"2007-05-20T09:07:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Steffen Prohaska writes:\n>\n>> But this is true not only for the upstream master but for every branch.\n>> The first-parent-path of any commit documents (at least in summaries)\n>> which features were introduced to the branch at which place. If a\n>> topic pulls from upstream, features already available in the upstream\n>> are introduced to the topic at this time. Why not summarize this?\n\nBecause it does not matter from the overall picture at that\npoint. In an earlier message I said that the summary is useful\nin a very short term -- the summary messages are useful while\nthe person who did the merge (or somebody who is simply\nfollowing him) is looking at near the tip of the branch, but\nwhen you are later viewing the older parts of the history from\n10,000 feet above, the distinction between what were pulled into\nthe local branch of the person who made the merge vs what the\nperson already had on the branch when he made the merge becomes\nmore or less irrelevant. The end result is that the project now\ngot the fruits of labor that happened on both sides.\n\n> Strictly speaking, it is not even correct with the upstream\n> master. I believe even my own 'maint' has fast forward merge\n> that I pulled from other people, and that part of the history if\n> you follow first-parent, you would not be following the \"project's\"\n> history (if there is such a thing, and if you are equating it\n> with \"JC's view of the history\").\n\nRegrettably, I have to say that --first-parent is, although it is\noften a useful way to get an approximation, a bad option that\ntends to instill a wrong mental model to people new to git.\n\nIn git, unlike CVS and SVN (I do not know now Monotone,\nMercurial and BitKeeper's branches work with this respect),\nbranches in git do not have their \"own\" identity in global\nhistory that is recorded in the commit ancestry graph. The only\nway you can ask \"how did this branch come about to this state?\"\nis to look at your own reflog, and that is strictly a local\nthing (i.e. the history as you observed it).\n\nEven when you are \"the upstream maintainer\" [*1*], there are\ncases where you pushed your tips out to the open, other people\nbuilt their work on top of it while you were not adding anything\nto your tree, and you end up pulling from them. Such a pull\nwill result in a fast-forward merge, and that is rightly so.\nThey did all the work, and the collective history of the project\nduring that time literally followed what the other person did,\nnot the \"upstream maintainer\". However, from the point of view\nof somebody who is following the upstream maintainer's tree,\nwhat he would observe is that at one point of the time the tip\nof the tree was the last commit the upstream maintainer pushed\nout (which became the base of the other person's work), and then\nthe next time you look at the tree there are bunch of commits by\nthe other person, appearing all at once even though there is no\n\"real\" merge commit that summarizes the work done on the \"side\nbranch\". Which some of the readers might feel a bit confusing\nand inconsistent, but that is really the correct interpretation\nof the history. The reason I feel --first-parent helps this\nconfusion is that people would think it would be consistent if\nwe do not allow fast-forward merges and instead always forced a\nreal merge in such a case (then you would consistently get the\nmerge summary). In other words, the first parent is not\ninherently special -- and people should view history that way,\nbut --first-parent and merge.summary give this false impression\nthat it is somehow special.\n\nAnyhow, enough rambling for a day. Now I have two releases\nto do tonight ;-)\n\n[Footnote]\n\n*1* In git, strictly speaking, there is no up or down, but as a\nsocial convention, I get updates from Shawn, Paulus, Bruce and\nfew other people via pull, and it would not be too incorrect to\nsay I'm more upstream than they are, and all others are more\ndownstream.\n"},{"id":"42723","messageId":"1179676829751-git-send-email-prohaska@zib.de","threadId":"8198","inReplyTo":"20070518215603.GS15393@fieldses.org","subject":"[PATCH] rev-list: '--indent' oneline output","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-20T16:00:29Z","receivedAt":"2007-05-20T16:00:29Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"Summaries in oneline output are indented to show the location of\nparents in merge commits. Indentation level is computed as the\nsmallest sum of parent locations along all paths that reach the\ncommit.\n\nAs a result, the output of\n git-rev-list --pretty=oneline --topo-order --indent\nis formatted in a way that resembles merge summaries. All commits that\nwere pulled from a branch are indented with one additional space below\nthe summary of the merge commit.\n\nWARNING: this patch changes the binary layout of commit.h. This could\nprobably be avoided by putting a bit more effort into the\nimplementation.\n\nSigned-off-by: Steffen Prohaska \n---\n builtin-rev-list.c | 7 ++++++-\n commit.h | 1 +\n revision.c | 19 +++++++++++++++----\n revision.h | 3 ++-\n 4 files changed, 24 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-rev-list.c b/builtin-rev-list.c\nindex ebf53f5..fd880b0 100644\n--- a/builtin-rev-list.c\n+++ b/builtin-rev-list.c\n@@ -50,6 +50,7 @@ static const char *header_prefix;\n \n static void show_commit(struct commit *commit)\n {\n+\tint i;\n \tif (show_timestamp)\n \t\tprintf(\"%lu \", commit->date);\n \tif (header_prefix)\n@@ -86,8 +87,12 @@ static void show_commit(struct commit *commit)\n \t\t parents = parents->next)\n \t\t\tparents->item->object.flags &= ~TMP_MARK;\n \t}\n-\tif (revs.commit_format == CMIT_FMT_ONELINE)\n+\tif (revs.commit_format == CMIT_FMT_ONELINE) {\n \t\tputchar(' ');\n+\t\tif (revs.indent)\n+\t\t\tfor (i = 0; i < commit->level; i++)\n+\t\t\t\tputchar(' ');\n+\t}\n \telse\n \t\tputchar('\\n');\n \ndiff --git a/commit.h b/commit.h\nindex 86e8dca..e0e7955 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -17,6 +17,7 @@ struct commit {\n \tstruct commit_list *parents;\n \tstruct tree *tree;\n \tchar *buffer;\n+\tint level;\n };\n \n extern int save_commit_buffer;\ndiff --git a/revision.c b/revision.c\nindex 0125d41..c965a23 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -372,7 +372,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str\n {\n \tstruct commit_list *parent = commit->parents;\n \tunsigned left_flag;\n-\tint add, rest;\n+\tint add, rest, indent;\n \n \tif (commit->object.flags & ADDED)\n \t\treturn 0;\n@@ -421,18 +421,24 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str\n \tleft_flag = (commit->object.flags & SYMMETRIC_LEFT);\n \n \trest = !revs->first_parent_only;\n-\tfor (parent = commit->parents, add = 1; parent; add = rest) {\n+\tfor (parent = commit->parents, add = 1, indent = 0; parent; add = rest, indent++) {\n \t\tstruct commit *p = parent->item;\n \n \t\tparent = parent->next;\n \t\tif (parse_commit(p) < 0)\n \t\t\treturn -1;\n \t\tp->object.flags |= left_flag;\n-\t\tif (p->object.flags & SEEN)\n+\t\tif (p->object.flags & SEEN) {\n+\t\t\tif (commit->level + indent < p->level) {\n+\t\t\t\tp->level = commit->level + indent;\n+\t\t\t}\n \t\t\tcontinue;\n+\t\t}\n \t\tp->object.flags |= SEEN;\n-\t\tif (add)\n+\t\tif (add) {\n+\t\t\tp->level = commit->level + indent;\n \t\t\tinsert_by_date(p, list);\n+\t\t}\n \t}\n \treturn 0;\n }\n@@ -1080,6 +1086,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\trevs->commit_format = get_commit_format(arg+8);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--indent\")) {\n+\t\t\t\trevs->indent = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--root\")) {\n \t\t\t\trevs->show_root_diff = 1;\n \t\t\t\tcontinue;\n@@ -1252,6 +1262,7 @@ int prepare_revision_walk(struct rev_info *revs)\n \t\tif (commit) {\n \t\t\tif (!(commit->object.flags & SEEN)) {\n \t\t\t\tcommit->object.flags |= SEEN;\n+\t\t\t\tcommit->level = 0;\n \t\t\t\tinsert_by_date(commit, &revs->commits);\n \t\t\t}\n \t\t}\ndiff --git a/revision.h b/revision.h\nindex 2845167..2a45955 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -63,7 +63,8 @@ struct rev_info {\n \n \t/* Format info */\n \tunsigned int\tshown_one:1,\n-\t\t\tabbrev_commit:1;\n+\t\t\tabbrev_commit:1,\n+\t\t\tindent:1;\n \tenum date_mode date_mode;\n \n \tconst char **ignore_packed; /* pretend objects in these are unpacked */\n-- \n1.5.2.rc3.88.g9f73-dirty\n"},{"id":"42727","messageId":"FAA26696-F444-4057-AED4-02B413B8A36D@zib.de","threadId":"8198","inReplyTo":"1179676829751-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] rev-list: '--indent' oneline output","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-20T16:12:10Z","receivedAt":"2007-05-20T16:12:10Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn May 20, 2007, at 6:00 PM, Steffen Prohaska wrote:\n\n> As a result, the output of\n> git-rev-list --pretty=oneline --topo-order --indent\n> is formatted in a way that resembles merge summaries. All commits that\n> were pulled from a branch are indented with one additional space below\n> the summary of the merge commit.\n\nI created the patch to illustrate how the history could be formatted to\nreplace summaries.\n\nFor example\n git-rev-list --pretty=oneline --topo-order --indent 404fdef2 | \ncut -d ' ' -f 2-\noutputs\n\nMerge branch 'maint'\n Documentation: Reformatted SYNOPSIS for several commands\n Documentation: Added [verse] to SYNOPSIS where necessary\n Documentation/git.txt: Update links to older documentation pages.\ngitweb: Fix \"Use of uninitialized value\" warning in git_feed\nMerge branch 'sp/cvsexport'\n Optimized cvsexportcommit: calling 'cvs status' once instead of \nonce per touched file.\nAdd link to 1.5.1.5 release notes.\nMerge 1.5.1.5 in\n GIT v1.5.1.5\n Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint\n user-manual: reorganize public git repo discussion\n user-manual: listing commits reachable from some refs not others\n user-manual: introduce git\n user-manual: add a \"counting commits\" example\n user-manual: move howto/using-topic-branches into manual\n user-manual: move howto/make-dist.txt into user manual\n Documentation: remove howto's now incorporated into manual\n user-manual: move quick-start to an appendix\n glossary: expand and clarify some definitions, prune cross-references\n user-manual: revise birdseye-view chapter\n Add a birdview-on-the-source-code section to the user manual\n Documentation: git-rev-list's \"patterns\"\ngitweb: Remove redundant $searchtype setup\n[...]\n\n- Steffen\n"},{"id":"42759","messageId":"7vveenl4u4.fsf@assigned-by-dhcp.cox.net","threadId":"8198","inReplyTo":"1179676829751-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] rev-list: '--indent' oneline output","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-20T18:36:51Z","receivedAt":"2007-05-20T18:36:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> Summaries in oneline output are indented to show the location of\n> parents in merge commits. Indentation level is computed as the\n> smallest sum of parent locations along all paths that reach the\n> commit.\n>\n> As a result, the output of\n> git-rev-list --pretty=oneline --topo-order --indent\n> is formatted in a way that resembles merge summaries. All commits that\n> were pulled from a branch are indented with one additional space below\n> the summary of the merge commit.\n\nI would have expected this kind of UI level tweak to be done not\nas a rev-list feature, but the subject of the e-mail to read\nsomething like \"--pretty=oneline: allow indentation levels\",\ni.e. wouldn't the feature apply not just rev-list but also\ngit-log?\n"},{"id":"42782","messageId":"200705202234.31717.robin.rosenberg.lists@dewire.com","threadId":"8198","inReplyTo":"alpine.LFD.0.98.0705181611520.3890@woody.linux-foundation.org","subject":"Re: merge summaries","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-05-20T20:34:31Z","receivedAt":"2007-05-20T20:34:31Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 19 maj 2007 skrev Linus Torvalds:\n> \n> On Fri, 18 May 2007, J. Bruce Fields wrote:\n> > \n> > I never quite understood what they're for--do they add any information\n> > not already available in the history? If not, and if people still find\n> > them helpful anyway, then I dunno, it looks like a sign of some sort of\n> > failure of our history display tools.\n> \n> I don't think they add much in the case of a graphical viewer, but for \n> \"git log\", it does make it look nicer..\n\nIt is nice for git-cvsexportcommit too. \n\n-- robin\n"},{"id":"42784","messageId":"CDD390B5-A67E-4510-9DAF-F0CB13AC8A4B@zib.de","threadId":"8198","inReplyTo":"7vveenl4u4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: '--indent' oneline output","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-05-20T20:38:23Z","receivedAt":"2007-05-20T20:38:23Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn May 20, 2007, at 8:36 PM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> Summaries in oneline output are indented to show the location of\n>> parents in merge commits. Indentation level is computed as the\n>> smallest sum of parent locations along all paths that reach the\n>> commit.\n>>\n>> As a result, the output of\n>> git-rev-list --pretty=oneline --topo-order --indent\n>> is formatted in a way that resembles merge summaries. All commits \n>> that\n>> were pulled from a branch are indented with one additional space \n>> below\n>> the summary of the merge commit.\n>\n> I would have expected this kind of UI level tweak to be done not\n> as a rev-list feature, but the subject of the e-mail to read\n> something like \"--pretty=oneline: allow indentation levels\",\n> i.e. wouldn't the feature apply not just rev-list but also\n> git-log?\n\nIt's only a proof of concept. I do not expect to see it added in\nthe current form. I'm not yet convinced if it's really a useful feature.\n\nI'm also not sure if changing 'struct commit' is a good idea.\ngitk is able to display the commit graph by parsing output of the\nexisting git-rev-list. It should be possible to do similar for log\nformatting without changing 'struct commit'.\n\n- Steffen\n"}]}