{"thread":{"id":"43169","subject":"Re: git-show --stat on first commit","startedAt":"2006-11-21T13:41:47Z","lastAt":"2006-11-24T09:04:11Z","messageCount":35,"participants":["Junio C Hamano","Peter Baumann","Petr Baudis","Jakub Narebski","Linus Torvalds","Shawn Pearce","Olivier Galibert","Andy Parkins","Santi Béjar","Carl Worth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298268","messageId":"200611211341.48862.andyparkins@gmail.com","threadId":"43169","inReplyTo":null,"subject":"git-show --stat on first commit","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-21T13:41:47Z","receivedAt":"2006-11-21T13:41:47Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI'm sure this one will be known about already. git-show --stat on the the \nfirst commit doesn't show anything. I assume it's because git-diff-tree has \nnothing to diff against (although shouldn't that be an everything-new diff?).\n\nGiven the above; does anyone have a suggestion for what I could use as a \nreplacement? Even just a list of the new files would be useful.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294283","messageId":"ejv0pq$g2d$1@sea.gmane.org","threadId":"43169","inReplyTo":"200611211341.48862.andyparkins@gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-21T14:01:57Z","receivedAt":"2006-11-21T14:01:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> I'm sure this one will be known about already. git-show --stat on the the \n> first commit doesn't show anything. I assume it's because git-diff-tree has \n> nothing to diff against (although shouldn't that be an everything-new diff?).\n\nYes, and git-diff-tree requires --root option if you want to generate\ncreation diff for initial (parentless, root) commit.\n \n> Given the above; does anyone have a suggestion for what I could use as a \n> replacement? Even just a list of the new files would be useful.\n\ngit show --stat --root\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297084","messageId":"8aa486160611210609h1c2d229ekf0b5e8aeb4f21f11@mail.gmail.com","threadId":"43169","inReplyTo":"200611211341.48862.andyparkins@gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-11-21T14:09:13Z","receivedAt":"2006-11-21T14:09:13Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 11/21/06, Andy Parkins wrote:\n> Hello,\n>\n> I'm sure this one will be known about already. git-show --stat on the the\n> first commit doesn't show anything. I assume it's because git-diff-tree has\n> nothing to diff against (although shouldn't that be an everything-new diff?).\n>\n> Given the above; does anyone have a suggestion for what I could use as a\n> replacement? Even just a list of the new files would be useful.\n\n$ git show --stat --root\n\nIn general the initial commit diff (or stat) is hidden, but perhaps it\nmake sense to show it in \"git show\", you asked fo this specifically.\n\n"},{"id":"298147","messageId":"slrnem694k.4lm.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"8aa486160611210609h1c2d229ekf0b5e8aeb4f21f11@mail.gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-21T16:08:52Z","receivedAt":"2006-11-21T16:08:52Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-21, Santi Béjar wrote:\n> On 11/21/06, Andy Parkins wrote:\n>> Hello,\n>>\n>> I'm sure this one will be known about already. git-show --stat on the the\n>> first commit doesn't show anything. I assume it's because git-diff-tree has\n>> nothing to diff against (although shouldn't that be an everything-new diff?).\n>>\n>> Given the above; does anyone have a suggestion for what I could use as a\n>> replacement? Even just a list of the new files would be useful.\n>\n> $ git show --stat --root\n>\n> In general the initial commit diff (or stat) is hidden, but perhaps it\n> make sense to show it in \"git show\", you asked fo this specifically.\n>\n> Santi\n\nWhy not make --root the default? I also stumbled over this behaviour and\neven asked on this list.\n\nIn my opinion this will help new users which are supprised that they\ncan't get the diff of the inital commit (which is totaly non-intuitiv behavior).\n\nAnd one less \"wart\" to clean, which another thread is all about. :-)\n\nPeter\n\n"},{"id":"296934","messageId":"ejv8pc$cig$1@sea.gmane.org","threadId":"43169","inReplyTo":"slrnem694k.4lm.Peter.B.Baumann@xp.machine.xx","subject":"Re: git-show --stat on first commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-21T16:18:15Z","receivedAt":"2006-11-21T16:18:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Peter Baumann wrote:\n\n> On 2006-11-21, Santi Béjar wrote:\n>> On 11/21/06, Andy Parkins wrote:\n>>> Hello,\n>>>\n>>> I'm sure this one will be known about already. git-show --stat on the the\n>>> first commit doesn't show anything. I assume it's because git-diff-tree has\n>>> nothing to diff against (although shouldn't that be an everything-new diff?).\n>>>\n>>> Given the above; does anyone have a suggestion for what I could use as a\n>>> replacement? Even just a list of the new files would be useful.\n\nYou can always use git-ls-tree\n\n>> $ git show --stat --root\n>>\n>> In general the initial commit diff (or stat) is hidden, but perhaps it\n>> make sense to show it in \"git show\", you asked fo this specifically.\n> \n> Why not make --root the default? I also stumbled over this behaviour and\n> even asked on this list.\n> \n> In my opinion this will help new users which are supprised that they\n> can't get the diff of the inital commit (which is totaly non-intuitiv behavior).\n> \n> And one less \"wart\" to clean, which another thread is all about. :-)\n\nBecause for projects imported into git first commit diff is huge,\nand not very interesting. By the way, git show by default doesn't show\ndiff for merges (you need --cc for that), nor rename detection (you need\n-M for that).\n\nBut you can always set default diff-tree options, including --root, --cc\nand -M in the show.difftree configuration variable (either in repo config,\nor in user config). It is IMHO better solution than changing defaults.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297265","messageId":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","threadId":"43169","inReplyTo":"slrnem694k.4lm.Peter.B.Baumann@xp.machine.xx","subject":"Re: git-show --stat on first commit","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-21T16:31:30Z","receivedAt":"2006-11-21T16:31:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 21 Nov 2006, Peter Baumann wrote:\n> \n> Why not make --root the default? I also stumbled over this behaviour and\n> even asked on this list.\n\nI suspect we should make the thing a config option, and default it to \n\"on\".\n\nI personally do _not_ want to see the root commit, because for the kernel, \nit's a honking huge import that does not make sense as a \"diff\". It's not \nreally a diff against anything, after all - it's an import.\n\nThat's really the reason why git defaults to not showing the root diff at \nall: exactly because for the kernel, the initial commit was state that \n\"just came to be\", and I found it both illogical and annoying to see it as \na diff, since that commit really was a \"black hole\" where previous history \njust disappeared.\n\nBut if you have the _full_ history with a new project, \"--root\" by default \nprobably makes tons of sense.\n\n> And one less \"wart\" to clean, which another thread is all about. :-)\n\nI really don't think it's a wart - see above - but it depends on the \nproject.\n\nThere's also another reason for the root being special, which is purely \ngit-internal: the root really has no parents at all, and the normal \"git \ndiff\" is \"diff against parents\". So from a purely implementation \nstandpoint, the \"root\" case is actually a special case, and for a while I \nwas kind of wondering whether I should do what a lot of other SCM's seem \nto do, namely start out with an \"empty root\" when doing \"git init-db\".\n\ngit didn't end up doing that (and I'm personally pretty happy about it), \nbut it was one of the things I was kind of thinking about: a \"git import\" \nkind of thing would have created an initial commit which was pre-populated \nwith the thing to import, and a \"git init-db\" would have created an \ninitial root commit that was empty.\n\nThat would have made the current \"don't show the root diff\" behaviour very \nnatural (and you'd still have gotten the initial diff for a new project), \nbut on the other hand, it would have had that annoying unnecessary \"init\" \ncommit, and you'd _still_ have wanted to have something like \"--root\" in \norder to show the import commit as a patch (which you _sometimes_ want to \ndo).\n\nSo having a config option would solve the problem, but what annoys me \nright now about the config options is that we really should have a \ngraphical front-end to setting those things or something, because while \n_I_ don't have any issues with editing a \".git/config\" file, I think we're \ngetting to the point where a lot of our problems are really about \"you can \ndo it, but you have to know a lot about git to even know you can do it\".\n\n"},{"id":"297973","messageId":"20061121164717.GB22006@spearce.org","threadId":"43169","inReplyTo":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","subject":"Re: git-show --stat on first commit","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-21T16:47:17Z","receivedAt":"2006-11-21T16:47:17Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> So having a config option would solve the problem, but what annoys me \n> right now about the config options is that we really should have a \n> graphical front-end to setting those things or something, because while \n> _I_ don't have any issues with editing a \".git/config\" file, I think we're \n> getting to the point where a lot of our problems are really about \"you can \n> do it, but you have to know a lot about git to even know you can do it\".\n\nFunny; I recently thought about rewriting Documentation/config.txt\ninto a format that was not only easily read by asciidoc but which\nalso had enough annotation data to render a Tk based UI from.\n\nThat way we could always have the configuration option editor match\nthe current set of configuration options, and also offer good help\nfor them. E.g. use a checkbox for booleans, a tk_optionMenu for\nchoice lists, and offer up the asciidoc text as \"help\" on the option.\n\nIts sort of in the back of my mind as something I'd like to do\nin git-gui, but right now branch management (creating, deleting,\nmerging) is more important.\n\n\nRight now git-gui does have a GUI editor for its own configuration\ndata that it keeps in \"gui\" sections of .git/config and\n~/.gitconfig, and lets the user view and edit both.\n\n-- \n"},{"id":"298661","messageId":"slrnem6cpn.6vh.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","subject":"Re: git-show --stat on first commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-21T17:11:19Z","receivedAt":"2006-11-21T17:11:19Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-21, Linus Torvalds wrote:\n>\n>\n> On Tue, 21 Nov 2006, Peter Baumann wrote:\n>> \n>> Why not make --root the default? I also stumbled over this behaviour and\n>> even asked on this list.\n>\n> I suspect we should make the thing a config option, and default it to \n> \"on\".\n>\nThat would be great.\n\n> I personally do _not_ want to see the root commit, because for the kernel, \n> it's a honking huge import that does not make sense as a \"diff\". It's not \n> really a diff against anything, after all - it's an import.\n>\n> That's really the reason why git defaults to not showing the root diff at \n> all: exactly because for the kernel, the initial commit was state that \n> \"just came to be\", and I found it both illogical and annoying to see it as \n> a diff, since that commit really was a \"black hole\" where previous history \n> just disappeared.\n>\n> But if you have the _full_ history with a new project, \"--root\" by default \n> probably makes tons of sense.\n>\n\nI am aware of the import problem, especially from the kernel history.\n\nAnd I think handling this behaviour as a config option is the right thing,\nbecause most of the time if someone imports a project into git he\nwill import the whole history, especially if he is using one of the\ncvs/svn importers. A \"halfway import\" as seen in the kernel repo is a\nspecial case and it is unlikely seen again.\n\nPeter\n"},{"id":"297912","messageId":"slrnem6d3i.7bn.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"ejv8pc$cig$1@sea.gmane.org","subject":"Re: git-show --stat on first commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-21T17:16:34Z","receivedAt":"2006-11-21T17:16:34Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-21, Jakub Narebski wrote:\n> Peter Baumann wrote:\n>\n>> On 2006-11-21, Santi Béjar wrote:\n>>> On 11/21/06, Andy Parkins wrote:\n>>>> Hello,\n>>>>\n>>>> I'm sure this one will be known about already. git-show --stat on the the\n>>>> first commit doesn't show anything. I assume it's because git-diff-tree has\n>>>> nothing to diff against (although shouldn't that be an everything-new diff?).\n>>>>\n>>>> Given the above; does anyone have a suggestion for what I could use as a\n>>>> replacement? Even just a list of the new files would be useful.\n>\n> You can always use git-ls-tree\n>\n>>> $ git show --stat --root\n>>>\n>>> In general the initial commit diff (or stat) is hidden, but perhaps it\n>>> make sense to show it in \"git show\", you asked fo this specifically.\n>> \n>> Why not make --root the default? I also stumbled over this behaviour and\n>> even asked on this list.\n>> \n>> In my opinion this will help new users which are supprised that they\n>> can't get the diff of the inital commit (which is totaly non-intuitiv behavior).\n>> \n>> And one less \"wart\" to clean, which another thread is all about. :-)\n>\n> Because for projects imported into git first commit diff is huge,\n> and not very interesting. By the way, git show by default doesn't show\n> diff for merges (you need --cc for that), nor rename detection (you need\n> -M for that).\n>\n> But you can always set default diff-tree options, including --root, --cc\n> and -M in the show.difftree configuration variable (either in repo config,\n> or in user config). It is IMHO better solution than changing defaults.\n\nAh. I wasn't aware of this. Thank for this nice tip.\n\nPeter\n"},{"id":"295798","messageId":"Pine.LNX.4.64.0611210913000.3338@woody.osdl.org","threadId":"43169","inReplyTo":"slrnem6cpn.6vh.Peter.B.Baumann@xp.machine.xx","subject":"Re: git-show --stat on first commit","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-21T17:20:06Z","receivedAt":"2006-11-21T17:20:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 21 Nov 2006, Peter Baumann wrote:\n> \n> And I think handling this behaviour as a config option is the right thing,\n> because most of the time if someone imports a project into git he\n> will import the whole history, especially if he is using one of the\n> cvs/svn importers. A \"halfway import\" as seen in the kernel repo is a\n> special case and it is unlikely seen again.\n\nActually, I see \"halfway imports\" all the time.\n\nI've found that some of the git things like \"git grep\" etc are _so_ \nconvenient, that whenever I get a source tar-ball for _anything_, I tend \nto do\n\n\tzcat < xyz-123.tar.gz | tar xvf -\n\tcd xyz-123\n\tgit init-db\n\tgit add\n\tgit commit -m \"Import xyz-123\"\n\nthe first thing I do. Even if I never end up changing anything in that \narchive, it's just that convenient (and fast - sure, doing the hashing and \ncompression means that the \"git add\" might not be truly instantaneous, but \nit's definitely fast enough that for almost all projects, doing this is so \ncheap that you don't need to care).\n\nAnd _especially_ for things like this, being able to do \"git log -p\" to \ncheck the small trivial one-liners that I might do is nice (it happens - \nmy pine4.64 import these days has three small commits to add buildnotes \nand handle UTF-8 input etc).\n\nAnd again, that's when you do _not_ want to see \"--root\". Because it's \nnever what you actually care about.\n\nSo I think imports are important. They may be throw-away trees like mine, \nbut they're still useful. \n\n"},{"id":"297320","messageId":"20061121180643.GC7201@pasky.or.cz","threadId":"43169","inReplyTo":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","subject":"Re: git-show --stat on first commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-21T18:06:43Z","receivedAt":"2006-11-21T18:06:43Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:\n> git didn't end up doing that (and I'm personally pretty happy about it), \n> but it was one of the things I was kind of thinking about: a \"git import\" \n> kind of thing would have created an initial commit which was pre-populated \n> with the thing to import, and a \"git init-db\" would have created an \n> initial root commit that was empty.\n> \n> That would have made the current \"don't show the root diff\" behaviour very \n> natural (and you'd still have gotten the initial diff for a new project), \n> but on the other hand, it would have had that annoying unnecessary \"init\" \n> commit, and you'd _still_ have wanted to have something like \"--root\" in \n> order to show the import commit as a patch (which you _sometimes_ want to \n> do).\n\nIt's being asked by users time by time (first in April last year ;) and\nI'm not sure about any good answer I should tell them, so is the reason\nfor not doing the implicit empty commit that it would be \"annoying\" I\nsuppose in the log output?\n\nIs that a reason good enough?\n\nIt would solve some of these annoying corner cases nicely, and you can\nstill hide this empty commit from log output etc.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"297351","messageId":"ejvfng$cj6$1@sea.gmane.org","threadId":"43169","inReplyTo":"20061121180643.GC7201@pasky.or.cz","subject":"Re: git-show --stat on first commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-21T18:16:44Z","receivedAt":"2006-11-21T18:16:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:\n>> git didn't end up doing that (and I'm personally pretty happy about it), \n>> but it was one of the things I was kind of thinking about: a \"git import\" \n>> kind of thing would have created an initial commit which was pre-populated \n>> with the thing to import, and a \"git init-db\" would have created an \n>> initial root commit that was empty.\n>> \n>> That would have made the current \"don't show the root diff\" behaviour very \n>> natural (and you'd still have gotten the initial diff for a new project), \n>> but on the other hand, it would have had that annoying unnecessary \"init\" \n>> commit, and you'd _still_ have wanted to have something like \"--root\" in \n>> order to show the import commit as a patch (which you _sometimes_ want to \n>> do).\n> \n> It's being asked by users time by time (first in April last year ;) and\n> I'm not sure about any good answer I should tell them, so is the reason\n> for not doing the implicit empty commit that it would be \"annoying\" I\n> suppose in the log output?\n\ngit repo-config show.difftree --root\ngit repo-config whatchanged.difftree --root\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294158","messageId":"20061121182135.GD7201@pasky.or.cz","threadId":"43169","inReplyTo":"ejvfng$cj6$1@sea.gmane.org","subject":"Re: git-show --stat on first commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-21T18:21:35Z","receivedAt":"2006-11-21T18:21:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:\n> Petr Baudis wrote:\n> \n> > On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:\n> >> git didn't end up doing that (and I'm personally pretty happy about it), \n> >> but it was one of the things I was kind of thinking about: a \"git import\" \n> >> kind of thing would have created an initial commit which was pre-populated \n> >> with the thing to import, and a \"git init-db\" would have created an \n> >> initial root commit that was empty.\n> >> \n> >> That would have made the current \"don't show the root diff\" behaviour very \n> >> natural (and you'd still have gotten the initial diff for a new project), \n> >> but on the other hand, it would have had that annoying unnecessary \"init\" \n> >> commit, and you'd _still_ have wanted to have something like \"--root\" in \n> >> order to show the import commit as a patch (which you _sometimes_ want to \n> >> do).\n> > \n> > It's being asked by users time by time (first in April last year ;) and\n> > I'm not sure about any good answer I should tell them, so is the reason\n> > for not doing the implicit empty commit that it would be \"annoying\" I\n> > suppose in the log output?\n> \n> git repo-config show.difftree --root\n> git repo-config whatchanged.difftree --root\n\nThat means extra pointless setup and is besides the point anyway, I was\nasking about empty commits, not default command settings.\n\nBTW, the other frequent reason why empty commits come up so frequently\nis a FAQ \"how do I create an unrelated branch in my repository\" - their\nidea is that they will create a new branch starting with an empty commit\n(of course noone would think of anything like that in inferior VCSes\nbecause replacing the checked out trees would took forever; how cool Git\nis!).\n\n(The answer is usually \"create the branch in a separate repo and then\nfetch it to the original one\". But it feels a bit kludgy given the\notherwise seamless support for unrelated branches. (Not that I ever was\na big fan of unrelated long-lived branches in general.))\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"296082","messageId":"20061121183445.GA22283@spearce.org","threadId":"43169","inReplyTo":"20061121182135.GD7201@pasky.or.cz","subject":"Re: git-show --stat on first commit","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-21T18:34:45Z","receivedAt":"2006-11-21T18:34:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> BTW, the other frequent reason why empty commits come up so frequently\n> is a FAQ \"how do I create an unrelated branch in my repository\" - their\n> idea is that they will create a new branch starting with an empty commit\n> (of course noone would think of anything like that in inferior VCSes\n> because replacing the checked out trees would took forever; how cool Git\n> is!).\n> \n> (The answer is usually \"create the branch in a separate repo and then\n> fetch it to the original one\". But it feels a bit kludgy given the\n> otherwise seamless support for unrelated branches. (Not that I ever was\n> a big fan of unrelated long-lived branches in general.))\n\nOr just abuse git-symbolic-ref:\n\n\trm .git/index\n\tgit symbolic-ref HEAD refs/heads/unrelated-branch\n\tgit add ...\n\tgit commit ...\n\nsee, so simple. And no need to create an unrelated repository and\npull across to this one...\n\n-- \n"},{"id":"296208","messageId":"20061121183853.GA61605@dspnet.fr.eu.org","threadId":"43169","inReplyTo":"slrnem6cpn.6vh.Peter.B.Baumann@xp.machine.xx","subject":"Re: git-show --stat on first commit","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-11-21T18:38:53Z","receivedAt":"2006-11-21T18:38:53Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:\n> And I think handling this behaviour as a config option is the right thing,\n> because most of the time if someone imports a project into git he\n> will import the whole history, especially if he is using one of the\n> cvs/svn importers. A \"halfway import\" as seen in the kernel repo is a\n> special case and it is unlikely seen again.\n\nNot all projects run on a public VCS. Hell, not all projects run on a\nVCS at all. And in the CVS case, you don't always have enough access\nto actually download the repository, which afaik is needed for\nimporting.\n\n OG.\n"},{"id":"297822","messageId":"87lkm4y77x.wl%cworth@cworth.org","threadId":"43169","inReplyTo":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","subject":"Re: git-show --stat on first commit","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-21T18:39:46Z","receivedAt":"2006-11-21T18:39:46Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote:\n> I suspect we should make the thing a config option, and default it to\n> \"on\".\n\nAgreed. That would be fabulous!\n\n> That's really the reason why git defaults to not showing the root diff at\n> all: exactly because for the kernel, the initial commit was state that\n> \"just came to be\", and I found it both illogical and annoying to see it as\n> a diff, since that commit really was a \"black hole\" where previous history\n> just disappeared.\n\nAh, that's a rationale I wouldn't have guessed.\n\n> There's also another reason for the root being special, which is purely\n> git-internal: the root really has no parents at all, and the normal \"git\n> diff\" is \"diff against parents\".\n\nThis is the rationale I was guessing was the cause. It clearly takes\na special case in the code to show the root diff, and --root seemed\nlike that special-case implementation leaking into the interface,\n(where, usually, the user wouldn't expect the first commit to be any\ndifferent than any other).\n\nThis looks like yet another case where a feature was added, and a new\ncommand-line option with it, when what was really wanted was a new\ndefault.\n\n> git didn't end up doing that (and I'm personally pretty happy about it),\n\nIt seems a reasonable enough decision, but it does have some\nimpacts. Several of the tools don't work in the strange state between\ngit-init and the first git-commit. Some of these are getting worked\nout now, (such as pull), but Junio was still objecting to fixing diff\nto work.\n\nThere's a decision to have git's internals support this intermediate\nstate, but all the tools should be made completely functional. This is\nan important things to get right, since this is the first state in\nwhich a new user will have her repository, (right after doing\ngit-init-db as the first step in the tutorial). So it's important to\nmake this state functional and not have to explain the \"strange\"\nimplementation details \"Normally, you would have a branch HEAD at this\npoint, so these commands would usually work even though they don't\nyet, etc. etc.\"\n\n> So having a config option would solve the problem,\n\nIf the default is fixed, yes.\n\n> but what annoys me\n> right now about the config options is that we really should have a\n> graphical front-end to setting those things or something, because while\n> _I_ don't have any issues with editing a \".git/config\" file, I think we're\n> getting to the point where a lot of our problems are really about \"you can\n> do it, but you have to know a lot about git to even know you can do it\".\n\nI agree with that statement. But I also think that for the \"new user\nproblems\" a new graphical tool for twiddling git options wouldn't make\nthe system any less imposing. On the other hand, getting the defaults\nto be less surprising would definitely help, (and configuration\noptions can be used to good effect to allow \"old-timers\" to maintain\nthe behavior they're used to as defaults change).\n\n-Carl\n"},{"id":"296869","messageId":"200611211839.58709.andyparkins@gmail.com","threadId":"43169","inReplyTo":"20061121182135.GD7201@pasky.or.cz","subject":"Re: git-show --stat on first commit","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-21T18:39:56Z","receivedAt":"2006-11-21T18:39:56Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2006, November 21 18:21, Petr Baudis wrote:\n\n> (The answer is usually \"create the branch in a separate repo and then\n> fetch it to the original one\". But it feels a bit kludgy given the\n> otherwise seamless support for unrelated branches. (Not that I ever was\n> a big fan of unrelated long-lived branches in general.))\n\nJust as kludgy, but I did this today by writing the name of the new branch \nin .git/HEAD then doing\n\nfor file in $(git-ls-files); do git-update-index --force-remove $file; done\n\nBefore creating the new files and \"git-commit\"ing.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"296626","messageId":"20061121184238.GC22283@spearce.org","threadId":"43169","inReplyTo":"20061121183853.GA61605@dspnet.fr.eu.org","subject":"Re: git-show --stat on first commit","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-21T18:42:38Z","receivedAt":"2006-11-21T18:42:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Olivier Galibert wrote:\n> On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:\n> > And I think handling this behaviour as a config option is the right thing,\n> > because most of the time if someone imports a project into git he\n> > will import the whole history, especially if he is using one of the\n> > cvs/svn importers. A \"halfway import\" as seen in the kernel repo is a\n> > special case and it is unlikely seen again.\n> \n> Not all projects run on a public VCS. Hell, not all projects run on a\n> VCS at all. And in the CVS case, you don't always have enough access\n> to actually download the repository, which afaik is needed for\n> importing.\n\nThere is a tool floating around the 'net that will download\na CVS repository and recreate the ,v files locally for you.\ncvssuck appears to be its name:\n\n http://freshmeat.net/projects/cvssuck/\n\n-- \n"},{"id":"297667","messageId":"20061121184817.GE7201@pasky.or.cz","threadId":"43169","inReplyTo":"200611211839.58709.andyparkins@gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-21T18:48:17Z","receivedAt":"2006-11-21T18:48:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:\n> On Tuesday 2006, November 21 18:21, Petr Baudis wrote:\n> \n> > (The answer is usually \"create the branch in a separate repo and then\n> > fetch it to the original one\". But it feels a bit kludgy given the\n> > otherwise seamless support for unrelated branches. (Not that I ever was\n> > a big fan of unrelated long-lived branches in general.))\n> \n> Just as kludgy, but I did this today by writing the name of the new branch \n> in .git/HEAD then doing\n> \n> for file in $(git-ls-files); do git-update-index --force-remove $file; done\n> \n> Before creating the new files and \"git-commit\"ing.\n\nOk, this approach looks actually reasonable (contrary to the frequently\nsuggested rm approach, which is rather dangerous).\n\nPerhaps git checkout --empty could do this?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"296154","messageId":"20061121185259.GA22461@spearce.org","threadId":"43169","inReplyTo":"20061121184817.GE7201@pasky.or.cz","subject":"Re: git-show --stat on first commit","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-21T18:52:59Z","receivedAt":"2006-11-21T18:52:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:\n> > for file in $(git-ls-files); do git-update-index --force-remove $file; done\n> > \n> > Before creating the new files and \"git-commit\"ing.\n> \n> Ok, this approach looks actually reasonable (contrary to the frequently\n> suggested rm approach, which is rather dangerous).\n> \n> Perhaps git checkout --empty could do this?\n\nOr perhaps just delete .git/index?\n\nAny git-update-index --add or git-add command will immediately create\nan empty index. Indeed this is the initial state after git-init-db,\nsince there is no HEAD to load into the index there is no index...\n\n-- \n"},{"id":"294349","messageId":"20061121190409.GF7201@pasky.or.cz","threadId":"43169","inReplyTo":"20061121185259.GA22461@spearce.org","subject":"Re: git-show --stat on first commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-21T19:04:09Z","receivedAt":"2006-11-21T19:04:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 21, 2006 at 07:52:59PM CET, Shawn Pearce wrote:\n> Petr Baudis wrote:\n> > On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:\n> > > for file in $(git-ls-files); do git-update-index --force-remove $file; done\n> > > \n> > > Before creating the new files and \"git-commit\"ing.\n> > \n> > Ok, this approach looks actually reasonable (contrary to the frequently\n> > suggested rm approach, which is rather dangerous).\n> > \n> > Perhaps git checkout --empty could do this?\n> \n> Or perhaps just delete .git/index?\n> \n> Any git-update-index --add or git-add command will immediately create\n> an empty index. Indeed this is the initial state after git-init-db,\n> since there is no HEAD to load into the index there is no index...\n\nBut your working tree has still the contents of the old branch.\n\nSure, you could possibly just remove the files and then the index at\nonce but that are just details.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"295198","messageId":"20061121190530.GG7201@pasky.or.cz","threadId":"43169","inReplyTo":"20061121183853.GA61605@dspnet.fr.eu.org","subject":"Re: git-show --stat on first commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-21T19:05:30Z","receivedAt":"2006-11-21T19:05:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 21, 2006 at 07:38:53PM CET, Olivier Galibert wrote:\n> On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:\n> > And I think handling this behaviour as a config option is the right thing,\n> > because most of the time if someone imports a project into git he\n> > will import the whole history, especially if he is using one of the\n> > cvs/svn importers. A \"halfway import\" as seen in the kernel repo is a\n> > special case and it is unlikely seen again.\n> \n> Not all projects run on a public VCS. Hell, not all projects run on a\n> VCS at all. And in the CVS case, you don't always have enough access\n> to actually download the repository, which afaik is needed for\n> importing.\n\nIt isn't needed. It's probably much slower over the net but that's how I\ncreated the glibc-cvs.git repository (at repo.or.cz); cvsps can operate\nover the network.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"293962","messageId":"7vmz6ky5ki.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"Pine.LNX.4.64.0611210820100.3338@woody.osdl.org","subject":"Re: git-show --stat on first commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-21T19:15:25Z","receivedAt":"2006-11-21T19:15:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 21 Nov 2006, Peter Baumann wrote:\n>> \n>> Why not make --root the default? I also stumbled over this behaviour and\n>> even asked on this list.\n>\n> I suspect we should make the thing a config option, and default it to \n> \"on\".\n>\n> I personally do _not_ want to see the root commit, because for the kernel, \n> it's a honking huge import that does not make sense as a \"diff\". It's not \n> really a diff against anything, after all - it's an import.\n>\n> That's really the reason why git defaults to not showing the root diff at \n> all: exactly because for the kernel, the initial commit was state that \n> \"just came to be\", and I found it both illogical and annoying to see it as \n> a diff, since that commit really was a \"black hole\" where previous history \n> just disappeared.\n>\n> But if you have the _full_ history with a new project, \"--root\" by default \n> probably makes tons of sense.\n\nI agree fully with the above. Let's make it happen.\n"},{"id":"295990","messageId":"7v64d8y4tu.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"20061121182135.GD7201@pasky.or.cz","subject":"Re: git-show --stat on first commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-21T19:31:25Z","receivedAt":"2006-11-21T19:31:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:\n>..\n>> git repo-config show.difftree --root\n>> git repo-config whatchanged.difftree --root\n>\n> That means extra pointless setup and is besides the point anyway, I was\n> asking about empty commits, not default command settings.\n\nI agree with you. Personally, I think:\n\n - show is where the user is asking for _that_ particular\n commit, so it can safely default to --root, always. No\n option is needed.\n\n - what we want for log and underlying rev-list is majorly\n dependent of the nature of the root commit. Per repository\n (or even per root) option which defaults to \"on\" (I was\n going to say \"off\" to be backward compatible and convenient\n for \"me\", but even Linus says \"on\" so I am playing along)\n would make sense.\n\nSo just \"core.showroot = yes | no\" would be the only thing we\nwould need, I think. Unless we do fancier \"core.hideroot =\nSHA1-1 SHA1-2 ...\" to say \"these root should not be shown\",\nthat is.\n\n> BTW, the other frequent reason why empty commits come up so frequently\n> is a FAQ \"how do I create an unrelated branch in my repository\" - their\n> idea is that they will create a new branch starting with an empty commit\n> (of course noone would think of anything like that in inferior VCSes\n> because replacing the checked out trees would took forever; how cool Git\n> is!).\n\nI wrote something about this after reading #git log several days\nago where somebody named Insount (sp?) was talking about\n\"elegant idea\" of the empty initial commit, but did not send it\nand kept silent about it. As Linus said in an earlier message,\nI've thought about this and am personally happy about the\ncurrent way of not having it, and here is why.\n\nInterestingly, I already talked about \"show --root\" in the\nmessage that I did not send -- I think you made this the right\nthread to post it in ;-)\n\n-- >8 --\nSubject: empty initial commit\n\nDon't do it. It is stupid.\n\n\tI'm imitating somebody who says \"I am so right that it\n hurts\". Don't worry, I'll come back to my usual self\n and talk about what is wrong with our current tools and\n what needs to be fixed shortly ;-).\n\n(1) Your claim that it is elegant because it removes a special\n case is bogus, because you are not removing special cases\n anyway.\n\nThe initial commit _is_ special. The first real example in\n\"everyday\" document begins by creating the initial commit out of\nan extracted tarball. You would _actively_ want to special case\nthat commit. Its diff from nothingness is so uninteresting\nwhile inspecting the development history of the project that we\ndo not even show it in \"git log -p\" output unless explicitly\nasked with \"--root\" option, for example [side note: we might\nwant to default to --root for \"git show\", which clearly\nindicates that the user is interested in that particular one\ncommit]. If you introduce the fake \"epoch\" commit, then you\nhave to move that special case logic elsewhere and squelch the\noutput when the parent is a commit with an empty tree, instead\nof the current logic which is to omit it when it is the root\ncommit. You have to have special case either way.\n\n(2) A branch yet to be born (i.e. a freshly initialized\n repository whose HEAD points at refs/heads/master that does\n not exist yet) and a branch whose tip points at a fake\n \"epoch\" commit are fundamentally different.\n\nLet's remember our GIT 101. Two commits that happen to have the\nsame tree are not equivalent, because a commit represents both\nthe then-current state when it was made _and_ the development\nhistory that led to it. The development history is represented\nby chains of commits.\n\nEarlier Linus and I updated git-pull to allow pulling into a\nbranch yet to be born because a branch yet to be born _is_ an\nancestor of any commit and can be fast-forwarded. There was no\nbranch and there was no earlier history.\n\nYou cannot say the same thing for a branch that points at a root\ncommit that has an empty tree. For one thing it would record\nauthorship information and stuff so it won't be \"THE universal\nvoid\". You can have infinite (well, bounded by 2^160 because we\nuse SHA-1 to name objects) such root commits, and they are not\nequivalent. Does that mean a true root commit (not your fake\ncommit) can be a child of 2^160 empty parents that are all\nalike? Which one of them do you choose to record as its parent\nand why?\n\nIf you start two branches with your scheme, they will have two\ndifferent fake root commits -- when merging these two branches\nthat were independently born, should these fake root commits be\ntreated as equivalents for merge-base computation? If so that\nintroduces a very special case that we currently do not need in\na very deep place. But we can already do a merge without common\nancestor just fine (I've done one myself and Linus did two), so\nthese 2^160 empty fake commits are not adding value to the\nsystem.\n\nOf course, you could use \"THE truly universal void\" commit that is\nby convention created in every git repository that has some\nagreed-upon author/committer/log information as that fake root\nand uniformly use it everywhere to solve the above, to emulate\nwhat we already do. But we have been doing fine without such a\nfake commit, thank you.\n\nSo it's stupid to introduce such a fake commit. Don't do it.\n\nNow, back to my usual self.\n\nI suspect that an independent branch creation inside an existing\nrepository is not an everyday event, and your complaint is\nprimarily coming from the fact that you somehow wanted to do\nthat recently and there was not a canned way to do so, not\nbecause you need to do that very often and the tool is lacking.\nBut for the moment, let's say it is an everyday event and making\nit easy to do so adds to the general value of our toolset.\n\nI think the real shortcoming of the current set of tools is that\nwhile it allows you to be initially on a yet-to-be-born branch,\nit does not offer you a way to be on another yet-to-be-born\nbranch once you created the first branch.\n\nThe command \"git branch $newbranch\" wants a commit to begin the\nnewly created branch at. Another, \"git checkout -b $newbranch\",\nhas the same property. If you do not give the starting commit,\nthey conveniently defaults to HEAD, which is inconvenient for\nwhat you want.\n\nSo it _is_ cumbersome to create (or, \"not to create\") and be on\na yet-to-be-born branch, and as a consequence, it is not\npossible unless you go down to bare plumbing level to start two\nunrelated histories in one repository. We do not give you a\ndirect way to do that. An obvious workaround is to create a new\nrepository to start a separate history afresh and fetch that\nbranch in, but if an independent branch creation had a valid\npurpose and were an everyday event, it certainly is merely a\nworkaround and shows that the toolset is lacking.\n\nMaybe a new option \"git checkout --void $newbranchname\", which\ndoes a rough equivalent of:\n\n\tnew=\"refs/heads/$newbranchname\"\n\tgit show-ref -q --verify \"$new\" &&\n die \"branch $newbranchname already exists\"\n\t# git ls-files -z | xargs -0 rm -f\n rm -f .git/index\n git symbolic-ref HEAD \"$new\"\n\nis what you would want to add. I am undecided about the\ncommented out part to remove everything from the working tree,\nthough. On one hand, if you are running \"git init-db\" in a\ndirectory full of files from an extracted tarball, we would not\ntouch any existing files, but on the other hand, since we are\ninterested in creating a totally unrelated history, losing\ntracked files feels more like the right thing to do.\n\nIn any case, I suspect you need to have a bit more convincing\nand persuasive argument why creating and maintaining more than\none, totally unrelated histories in a single repository is\nnecessary.\n\nAnd \"git.git has more than one roots and it looks kinda cool\" is\nnot a convincing argument at all. For one thing, these roots\nwere not created in a single repository. The true git root was\ndone in Linus's dircache project back when there was no multiple\nbranches, gitk, git-tools and gitweb were all done in their own\nseparate repositories and later merged in to be part of the\ncurrent tip of the master.\n\nTodo, html and man roots all come from their own separate\nrepositories and because they are not part of the history of the\ngit development they are still independent. \n\nThe real reason I have \"todo\" in git.git was because the parent\ndirectory /pub/scm/git/ was not writable to me at kernel.org and\nI was too lazy to ask for ownership/permission changed when I\ntook over /pub/scm/git/git.git; I otherwise would have created a\nseparate git-todo.git next to git.git there.\n\nAnd the reason html and man roots are in git.git is because\nhaving \"todo\" in git.git turned out to be not-so-disastrous as I\nfeared when I first did so, and it seemed like an interesting\nway to experiment on the \"central place to distribute unrelated\nstuff\" idea. But they come from their own separate\nrepositories.\n\nBy the way, I would solve B1..B100 merge issue without special\ncasing by:\n\n\tgit checkout -b merged B$(pick-randomly 1 100)\n i=1\n while test $i -le 100\n do\n \tgit pull . B$i\n i=$(($i + 1))\n\tdone\n\nStarting from a randomly picked parent and starting from an void\n(created with \"git checkout --void\" we discussed above) would\ngive you exactly the same result because pulling B$i on top of\nB$i (or something that already has merged B$i) is a fast\nforward.\n\n"},{"id":"298546","messageId":"ejvlv9$781$1@sea.gmane.org","threadId":"43169","inReplyTo":"7v64d8y4tu.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-show --stat on first commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-21T20:03:18Z","receivedAt":"2006-11-21T20:03:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Petr Baudis writes:\n> \n>> On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:\n>>..\n>>> git repo-config show.difftree --root\n>>> git repo-config whatchanged.difftree --root\n>>\n>> That means extra pointless setup and is besides the point anyway, I was\n>> asking about empty commits, not default command settings.\n> \n> I agree with you. Personally, I think:\n> \n> - show is where the user is asking for _that_ particular\n> commit, so it can safely default to --root, always. No\n> option is needed.\n\nWe don't show patch for merges by default in git-show, so I don't\nsee why we would want to show root commit diff in git-show by default:\nthose two are very similar.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298232","messageId":"200611230925.07821.andyparkins@gmail.com","threadId":"43169","inReplyTo":"ejvlv9$781$1@sea.gmane.org","subject":"Re: git-show --stat on first commit","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-23T09:25:06Z","receivedAt":"2006-11-23T09:25:06Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2006 November 21 20:03, Jakub Narebski wrote:\n\n> We don't show patch for merges by default in git-show, so I don't\n> see why we would want to show root commit diff in git-show by default:\n> those two are very similar.\n\n$ git init-db\n$ date > file1\n$ git add file1; git commit -a -m \"file1 added\"\n$ date > file2\n$ git add file2; git commit -a -m \"file2 added\"\n$ git show --stat HEAD\n$ git show --stat HEAD^\n\nI can understand while people get confused. Two patches, both add a file. \ngit-show on one of them shows a stat; on the other it doesn't.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294022","messageId":"slrnemaqt1.esn.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"7v64d8y4tu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-23T09:36:33Z","receivedAt":"2006-11-23T09:36:33Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"This allows one to see the root commit as a diff in commands like git-log,\ngit-show and git-whatchanged. It also modifies git-diff-tree to act as --root\nwas specified on the commandline. The default is set to true.\n\nSigned-off-by: Peter Baumann \n---\nI'm not sure if making core.showroot acting on git-diff-tree is the\nright thing to do. Please check first bevore applying.\n\n Documentation/config.txt | 6 ++++++\n builtin-diff-tree.c | 1 +\n builtin-log.c | 3 +++\n cache.h | 1 +\n config.c | 5 +++++\n environment.c | 1 +\n 6 files changed, 17 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 9d3c71c..7e600ca 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -110,6 +110,12 @@ core.legacyheaders::\n \tdatabase directly (where the \"http://\" and \"rsync://\" protocols\n \tcount as direct access).\n \n+core.showroot::\n+\tIf true, the initial commit will be shown as a big creation event.\n+\tThis is equivalent to a diff against an empty tree.\n+\tTools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which\n+\tnormally hide the root commit will now show it. True by default.\n+\n alias.*::\n \tCommand aliases for the gitlink:git[1] command wrapper - e.g.\n \tafter defining \"alias.last = cat-file commit HEAD\", the invocation\ndiff --git a/builtin-diff-tree.c b/builtin-diff-tree.c\nindex 24cb2d7..d58b7ca 100644\n--- a/builtin-diff-tree.c\n+++ b/builtin-diff-tree.c\n@@ -72,6 +72,7 @@ int cmd_diff_tree(int argc, const char *\n \tnr_sha1 = 0;\n \topt->abbrev = 0;\n \topt->diff = 1;\n+\topt->show_root_diff = show_root_diff;\n \targc = setup_revisions(argc, argv, opt, NULL);\n \n \twhile (--argc > 0) {\ndiff --git a/builtin-log.c b/builtin-log.c\nindex fedb013..9541c7d 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -53,6 +53,7 @@ int cmd_whatchanged(int argc, const char\n \trev.diff = 1;\n \trev.diffopt.recursive = 1;\n \trev.simplify_history = 0;\n+\trev.show_root_diff = show_root_diff;\n \tcmd_log_init(argc, argv, prefix, &rev);\n \tif (!rev.diffopt.output_format)\n \t\trev.diffopt.output_format = DIFF_FORMAT_RAW;\n@@ -72,6 +73,7 @@ int cmd_show(int argc, const char **argv\n \trev.always_show_header = 1;\n \trev.ignore_merges = 0;\n \trev.no_walk = 1;\n+\trev.show_root_diff = show_root_diff;\n \tcmd_log_init(argc, argv, prefix, &rev);\n \treturn cmd_log_walk(&rev);\n }\n@@ -83,6 +85,7 @@ int cmd_log(int argc, const char **argv,\n \tgit_config(git_diff_ui_config);\n \tinit_revisions(&rev, prefix);\n \trev.always_show_header = 1;\n+\trev.show_root_diff = show_root_diff;\n \tcmd_log_init(argc, argv, prefix, &rev);\n \treturn cmd_log_walk(&rev);\n }\ndiff --git a/cache.h b/cache.h\nindex f2ec5c8..feff2bd 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -191,6 +191,7 @@ extern int warn_ambiguous_refs;\n extern int shared_repository;\n extern const char *apply_default_whitespace;\n extern int zlib_compression_level;\n+extern int show_root_diff;\n \n #define GIT_REPO_VERSION 0\n extern int repository_format_version;\ndiff --git a/config.c b/config.c\nindex 3cae390..dd720b5 100644\n--- a/config.c\n+++ b/config.c\n@@ -319,6 +319,11 @@ int git_default_config(const char *var,\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.showroot\")) {\n+\t\tshow_root_diff = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \t/* Add other config variables here and to Documentation/config.txt. */\n \treturn 0;\n }\ndiff --git a/environment.c b/environment.c\nindex 84d870c..71099f4 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -24,6 +24,7 @@ const char *apply_default_whitespace;\n int zlib_compression_level = Z_DEFAULT_COMPRESSION;\n int pager_in_use;\n int pager_use_color = 1;\n+int show_root_diff = 1;\n \n static const char *git_dir;\n static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;\n-- \n1.4.3.3\n\n"},{"id":"297868","messageId":"7virh5khrc.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"slrnemaqt1.esn.Peter.B.Baumann@xp.machine.xx","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-23T20:52:39Z","receivedAt":"2006-11-23T20:52:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann \nwrites:\n\n> This allows one to see the root commit as a diff in commands like git-log,\n> git-show and git-whatchanged. It also modifies git-diff-tree to act as --root\n> was specified on the commandline. The default is set to true.\n>\n> Signed-off-by: Peter Baumann \n> ---\n> I'm not sure if making core.showroot acting on git-diff-tree is the\n> right thing to do. Please check first bevore applying.\n\nI agree that this \"use --root by default\" belongs to Porcelain\nlayer, not the plumbing. We would probably want to do this in\nthe same way as we do the color in diff.c::git_diff_ui_config().\n\n\n\n\n"},{"id":"295948","messageId":"slrnemcc0b.ncc.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"7virh5khrc.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-23T23:34:35Z","receivedAt":"2006-11-23T23:34:35Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-23, Junio C Hamano wrote:\n> Peter Baumann \n> writes:\n>\n>> This allows one to see the root commit as a diff in commands like git-log,\n>> git-show and git-whatchanged. It also modifies git-diff-tree to act as --root\n>> was specified on the commandline. The default is set to true.\n>>\n>> Signed-off-by: Peter Baumann \n>> ---\n>> I'm not sure if making core.showroot acting on git-diff-tree is the\n>> right thing to do. Please check first bevore applying.\n>\n> I agree that this \"use --root by default\" belongs to Porcelain\n> layer, not the plumbing. We would probably want to do this in\n> the same way as we do the color in diff.c::git_diff_ui_config().\n>\nSorry, but I don't understand. The color handling doesn't look any different\nto me than the handling of the other config entrys. Did I miss something?\n\nPeter\n"},{"id":"294626","messageId":"7vejrthf2y.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"slrnemcc0b.ncc.Peter.B.Baumann@xp.machine.xx","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-24T00:18:45Z","receivedAt":"2006-11-24T00:18:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann \nwrites:\n\n>>> I'm not sure if making core.showroot acting on git-diff-tree is the\n>>> right thing to do. Please check first bevore applying.\n>>\n>> I agree that this \"use --root by default\" belongs to Porcelain\n>> layer, not the plumbing. We would probably want to do this in\n>> the same way as we do the color in diff.c::git_diff_ui_config().\n>>\n> Sorry, but I don't understand. The color handling doesn't look any different\n> to me than the handling of the other config entrys. Did I miss something?\n\n\"git-diff-tree --color HEAD\" (with explicit command line\ninstruction to color it) still colours its output, but \"[diff]\ncolor = auto\" in ~/.gitconfig would not affect the coloring.\nHence, \"git-diff-tree HEAD\" with the configuration entry gives\nmonochrome.\n\n\"git diff HEAD\" on the other hand looks at '[diff] color = auto\"\nand will color its output without being told on the command\nline.\n\n\n\n"},{"id":"296379","messageId":"7vzmahfx6q.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"7vejrthf2y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-24T01:30:37Z","receivedAt":"2006-11-24T01:30:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Peter Baumann \n> writes:\n>\n>> Sorry, but I don't understand. The color handling doesn't look any different\n>> to me than the handling of the other config entrys. Did I miss something?\n>\n> \"git-diff-tree --color HEAD\" (with explicit command line\n> instruction to color it) still colours its output, but \"[diff]\n> color = auto\" in ~/.gitconfig would not affect the coloring.\n> Hence, \"git-diff-tree HEAD\" with the configuration entry gives\n> monochrome.\n>\n> \"git diff HEAD\" on the other hand looks at '[diff] color = auto\"\n> and will color its output without being told on the command\n> line.\n\nSince this is about \"log\" family that deals with revision\nstructure, how about....\n\n-- >8 --\n[PATCH] config option log.showroot to show the diff of root commits\n\nFrom: Peter Baumann \n\nThis allows one to see a root commit as a diff in commands like git-log,\ngit-show and git-whatchanged.\n\nSigned-off-by: Peter Baumann \nSigned-off-by: Junio C Hamano \n---\n Documentation/config.txt | 6 ++++++\n builtin-log.c | 20 ++++++++++++++++----\n 2 files changed, 22 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 9d3c71c..9090762 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -219,6 +219,12 @@ i18n.commitEncoding::\n \tbrowser (and possibly at other places in the future or in other\n \tporcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.\n \n+log.showroot::\n+\tIf true, the initial commit will be shown as a big creation event.\n+\tThis is equivalent to a diff against an empty tree.\n+\tTools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which\n+\tnormally hide the root commit will now show it. True by default.\n+\n merge.summary::\n \tWhether to include summaries of merged commits in newly created\n \tmerge commit messages. False by default.\ndiff --git a/builtin-log.c b/builtin-log.c\nindex fedb013..7acf5d3 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -13,6 +13,8 @@\n #include \n #include \n \n+static int default_show_root = 1;\n+\n /* this is in builtin-diff.c */\n void add_head(struct rev_info *revs);\n \n@@ -22,6 +24,7 @@ static void cmd_log_init(int argc, const\n \trev->abbrev = DEFAULT_ABBREV;\n \trev->commit_format = CMIT_FMT_DEFAULT;\n \trev->verbose_header = 1;\n+\trev->show_root_diff = default_show_root;\n \targc = setup_revisions(argc, argv, rev, \"HEAD\");\n \tif (rev->diffopt.pickaxe || rev->diffopt.filter)\n \t\trev->always_show_header = 0;\n@@ -44,11 +47,20 @@ static int cmd_log_walk(struct rev_info\n \treturn 0;\n }\n \n+static int git_log_config(const char *var, const char *value)\n+{\n+\tif (!strcmp(var, \"log.showroot\")) {\n+\t\tdefault_show_root = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\treturn git_diff_ui_config(var, value);\n+}\n+\n int cmd_whatchanged(int argc, const char **argv, const char *prefix)\n {\n \tstruct rev_info rev;\n \n-\tgit_config(git_diff_ui_config);\n+\tgit_config(git_log_config);\n \tinit_revisions(&rev, prefix);\n \trev.diff = 1;\n \trev.diffopt.recursive = 1;\n@@ -63,7 +75,7 @@ int cmd_show(int argc, const char **argv\n {\n \tstruct rev_info rev;\n \n-\tgit_config(git_diff_ui_config);\n+\tgit_config(git_log_config);\n \tinit_revisions(&rev, prefix);\n \trev.diff = 1;\n \trev.diffopt.recursive = 1;\n@@ -80,7 +92,7 @@ int cmd_log(int argc, const char **argv,\n {\n \tstruct rev_info rev;\n \n-\tgit_config(git_diff_ui_config);\n+\tgit_config(git_log_config);\n \tinit_revisions(&rev, prefix);\n \trev.always_show_header = 1;\n \tcmd_log_init(argc, argv, prefix, &rev);\n@@ -109,7 +121,7 @@ static int git_format_config(const char\n \tif (!strcmp(var, \"diff.color\")) {\n \t\treturn 0;\n \t}\n-\treturn git_diff_ui_config(var, value);\n+\treturn git_log_config(var, value);\n }\n \n \n-- \n1.4.4.1.g77614\n\n"},{"id":"295502","messageId":"200611240849.53510.jnareb@gmail.com","threadId":"43169","inReplyTo":"200611230925.07821.andyparkins@gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-24T07:49:53Z","receivedAt":"2006-11-24T07:49:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n> On Tuesday 2006 November 21 20:03, Jakub Narebski wrote:\n> \n>> We don't show patch for merges by default in git-show, so I don't\n>> see why we would want to show root commit diff in git-show by default:\n>> those two are very similar.\n> \n> $ git init-db\n> $ date > file1\n> $ git add file1; git commit -a -m \"file1 added\"\n> $ date > file2\n> $ git add file2; git commit -a -m \"file2 added\"\n> $ git show --stat HEAD\n> $ git show --stat HEAD^\n> \n> I can understand while people get confused. Two patches, both add a file. \n> git-show on one of them shows a stat; on the other it doesn't.\n\nWell, perhaps \"git show --stat\" should show diffstat also for root\ncommit, because it shows diffstat for merges (although not patch),\nbut not patch (which usually is huge).\n-- \nJakub Narebski\n"},{"id":"295458","messageId":"slrnemd98k.a3v.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"7vzmahfx6q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-24T07:53:56Z","receivedAt":"2006-11-24T07:53:56Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-24, Junio C Hamano wrote:\n>> \"git-diff-tree --color HEAD\" (with explicit command line\n>> instruction to color it) still colours its output, but \"[diff]\n>> color = auto\" in ~/.gitconfig would not affect the coloring.\n>> Hence, \"git-diff-tree HEAD\" with the configuration entry gives\n>> monochrome.\n>>\n>> \"git diff HEAD\" on the other hand looks at '[diff] color = auto\"\n>> and will color its output without being told on the command\n>> line.\n>\n> Since this is about \"log\" family that deals with revision\n> structure, how about....\n>\n> -- >8 --\n> [PATCH] config option log.showroot to show the diff of root commits\n[...]\n\nPatch looks good.\n\nOne question, what's the difference between git-log -p and git-whatchanged -p?\nI could only see it differ in the root commit handling.\n\nInteresting parts marked with | as first character of the line.\n\n git-repo-config --get log.showroot\n false\n\n git-log -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68\n commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68\n Author: Linus Torvalds \n Date: Thu Apr 7 15:16:10 2005 -0700\n\n Add copyright notices.\n\n The tool interface sucks (especially \"committing\" information, which is just\n me doing everything by hand from the command line), but I think this is in\n theory actually a viable way of describing the world. So copyright it.\n\n diff --git a/cat-file.c b/cat-file.c\n index 74a0a23..d8f0121 100644\n --- a/cat-file.c\n +++ b/cat-file.c\n @@ -1,3 +1,8 @@\n +/*\n + * GIT - The information manager from hell\n + *\n + * Copyright (C) Linus Torvalds, 2005\n + */\n #include \"cache.h\"\n\n int main(int argc, char **argv)\n\n [... rest of the diff ...]\n\n| commit e83c5163316f89bfbde7d9ab23ca2e25604af290\n| Author: Linus Torvalds \n| Date: Thu Apr 7 15:13:13 2005 -0700\n|\n| Initial revision of \"git\", the information manager from hell\n|\n [ ... as specified in log.showroot, no diff of the root commit ...]\n\n git-whatchanged -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68\n commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68\n Author: Linus Torvalds \n Date: Thu Apr 7 15:16:10 2005 -0700\n \n Add copyright notices.\n \n The tool interface sucks (especially \"committing\" information, which is just\n me doing everything by hand from the command line), but I think this is in\n theory actually a viable way of describing the world. So copyright it.\n \n diff --git a/cat-file.c b/cat-file.c\n index 74a0a23..d8f0121 100644\n --- a/cat-file.c\n +++ b/cat-file.c\n @@ -1,3 +1,8 @@\n +/*\n + * GIT - The information manager from hell\n + *\n + * Copyright (C) Linus Torvalds, 2005\n + */\n #include \"cache.h\"\n \n int main(int argc, char **argv)\n\n [... rest of the diff ...]\n|\n| [ ... no commit message etc from the root commit is shown ...]\n|\n\nAs you can see, the root commit isn't shown. Is this intentional?\nOr is it just me not getting the different meaning of git-log and\ngit-whatchanged?\n\nSetting \"log.showroot = true\" the output of the 2 commands is identical.\n\nPeter\n"},{"id":"298628","messageId":"7vlkm1cjht.fsf@assigned-by-dhcp.cox.net","threadId":"43169","inReplyTo":"slrnemd98k.a3v.Peter.B.Baumann@xp.machine.xx","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-24T08:54:38Z","receivedAt":"2006-11-24T08:54:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann \nwrites:\n\n> One question, what's the difference between git-log -p and\n> git-whatchanged -p?\n> ...\n> As you can see, the root commit isn't shown. Is this intentional?\n\nSome historical background.\n\nThe traditional command do do log-minded things was whatchanged\nand it was implemented as\n\n\tgit rev-list $revision_args -- $path_limits |\n git diff-tree --stdin --pretty -r $format_args\n\nand whatchanged did not give --root to diff-tree by default.\nAnd 'diff-tree' does not show --pretty logs when there is no\ndiff to be shown (which still is true today and is a useful\nbehaviour), hence no mention of the root commit.\n\nOn the other hand, \"git-log\" traditionally looked like this:\n\n\tgit rev-list --pretty $revision_args \n\nBack then, there was no path_limits nor even diff options to\nit.\n\nLater, Linus (with help from others) made the revision walk\nmachinery as callable inside programs other than \"rev-list\",\neliminating the need to pipe rev-list into diff-tree to perform\nlog-minded things. That enriched what \"git log\" can do, and\nmostly made \"whatchanged\" a redundant command. As you may have\nnoticed, there isn't much difference between these two commands\nin builtin-log.c; their differences are solely what default\noptions for diff and revision machinery are used and are meant\nto match the traditional behaviour of these commands.\n\nSo there shouldn't be any differences, really, when you override\ntheir defaults with the likes of -p.\n\nHonestly speaking, I do not think there was _any_ consciously\ndesigned intention to handle root commits, either to make these\ncommands behave identically or differently; regarding parentless\ncommits, they just behave the way they happen to behave, because\nroot commits were not something either Linus nor I were\ninterested in.\n\nGiven the recent discussion, however, the intention now should\nbe that Porcelain level commands should default to do --root\n(i.e. when asked to do \"diff\" to show how a commit without a\nparent differs from its nonexistent parent, show diff with\nemptiness).\n"},{"id":"296381","messageId":"slrnemddcb.ggq.Peter.B.Baumann@xp.machine.xx","threadId":"43169","inReplyTo":"7vlkm1cjht.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] config option core.showroot to enable showing the diff of the root commit","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-11-24T09:04:11Z","receivedAt":"2006-11-24T09:04:11Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-11-24, Junio C Hamano wrote:\n> Peter Baumann \n> writes:\n>\n>> One question, what's the difference between git-log -p and\n>> git-whatchanged -p?\n>> ...\n>> As you can see, the root commit isn't shown. Is this intentional?\n>\n> Some historical background.\n>\n> The traditional command do do log-minded things was whatchanged\n> and it was implemented as\n>\n> \tgit rev-list $revision_args -- $path_limits |\n> git diff-tree --stdin --pretty -r $format_args\n>\n> and whatchanged did not give --root to diff-tree by default.\n> And 'diff-tree' does not show --pretty logs when there is no\n> diff to be shown (which still is true today and is a useful\n> behaviour), hence no mention of the root commit.\n>\n> On the other hand, \"git-log\" traditionally looked like this:\n>\n> \tgit rev-list --pretty $revision_args \n>\n> Back then, there was no path_limits nor even diff options to\n> it.\n>\n> Later, Linus (with help from others) made the revision walk\n> machinery as callable inside programs other than \"rev-list\",\n> eliminating the need to pipe rev-list into diff-tree to perform\n> log-minded things. That enriched what \"git log\" can do, and\n> mostly made \"whatchanged\" a redundant command. As you may have\n> noticed, there isn't much difference between these two commands\n> in builtin-log.c; their differences are solely what default\n> options for diff and revision machinery are used and are meant\n> to match the traditional behaviour of these commands.\n>\n> So there shouldn't be any differences, really, when you override\n> their defaults with the likes of -p.\n>\n> Honestly speaking, I do not think there was _any_ consciously\n> designed intention to handle root commits, either to make these\n> commands behave identically or differently; regarding parentless\n> commits, they just behave the way they happen to behave, because\n> root commits were not something either Linus nor I were\n> interested in.\n>\n> Given the recent discussion, however, the intention now should\n> be that Porcelain level commands should default to do --root\n> (i.e. when asked to do \"diff\" to show how a commit without a\n> parent differs from its nonexistent parent, show diff with\n> emptiness).\n>\n\nAh. I see. Thanks for the clarification.\n\nPeter\n"}]}