{"thread":{"id":"4878","subject":"Kernel headers git tree","startedAt":"2006-07-13T23:59:09Z","lastAt":"2006-07-24T23:23:39Z","messageCount":27,"participants":["David Woodhouse","Junio C Hamano","Linus Torvalds","Ian Campbell","Daniel Barkalow","Ingo Oeser","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23788","messageId":"1152835150.31372.23.camel@shinybook.infradead.org","threadId":"4878","inReplyTo":null,"subject":"Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-13T23:59:09Z","receivedAt":"2006-07-13T23:59:09Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git\nthere's a git tree which contains the sanitised exported headers for all\narchitectures -- basically the result of 'make headers_install'.\n\nIt tracks Linus' kernel tree, by means of some evil scripts.¹\n\nOnly commits in Linus' tree which actually affect the exported result\nshould have an equivalent commit in the above tree, which means that any\nchanges which affect userspace should be clearly visible for review.\n\n-- \ndwmw2\n\n¹ http://david.woodhou.se/extract-khdrs-git.sh and\n  http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach\n"},{"id":"23789","messageId":"7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net","threadId":"4878","inReplyTo":"1152835150.31372.23.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-14T00:39:55Z","receivedAt":"2006-07-14T00:39:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Woodhouse <dwmw2@infradead.org> writes:\n\n> ¹ http://david.woodhou.se/extract-khdrs-git.sh and\n>   http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach\n\nWith modern enough git, you can rewrite\n\n\tKBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\\  | cut -f1`\n\nwith\n\n\tKBUILDSHA1=`git rev-parse $TREE:Kbuild`\n\nI am not sure what function incparent() is trying to do with\nthis:\n\n\tgit rev-list --max-count=1 --topo-order $1 -- .\n"},{"id":"23790","messageId":"1152838562.31372.58.camel@shinybook.infradead.org","threadId":"4878","inReplyTo":"7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T00:56:01Z","receivedAt":"2006-07-14T00:56:01Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:\n> With modern enough git, you can rewrite\n>         KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\\  | cut -f1`\n> with\n>         KBUILDSHA1=`git rev-parse $TREE:Kbuild`\n\n\nAha. Thanks.\n\n> I am not sure what function incparent() is trying to do with\n> this:\n> \n>         git rev-list --max-count=1 --topo-order $1 -- . \n\nFind the latest ancestor commit which actually changed any files. The\nfirst script has a similar line, except that it finds the latest\nancestor which changed anything in include/\n\nConsider a kernel tree with commits A-->B-->C-->D, of which only A and C\nchange anything in include/ and in fact only C actually changes the\n_exported_ headers after the unifdef and sed bits. \n\nThe first script (extract-khdrs-git.sh) creates a 'stage1' branch which\nonly contains commits A'-->C', with the _exported_ header tree for each.\n\nThe second script (extract-khdrs-stage2.sh) then creates the master\nbranch with the same tree objects, but omitting the commits which don't\nchange anything. So it contains only commit C''\n\nFor an example of this, compare\nhttp://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git\nwith\nhttp://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git;a=shortlog;h=stage1\n\nBtw, git-rev-list is _very_ slow at this. Even when the output is\nactually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:\n\npmac /pmac/git/linux-2.6 $ git-rev-parse HEAD\nab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\npmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include\nab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\n\nreal    0m18.840s\n\nIs there a better way to do that step?\n\n-- \ndwmw2\n"},{"id":"23791","messageId":"Pine.LNX.4.64.0607131800520.5623@g5.osdl.org","threadId":"4878","inReplyTo":"7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T01:05:47Z","receivedAt":"2006-07-14T01:05:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 13 Jul 2006, Junio C Hamano wrote:\n> \n> I am not sure what function incparent() is trying to do with\n> this:\n> \n> \tgit rev-list --max-count=1 --topo-order $1 -- .\n\nYeah, that looks strange.\n\nThe \"--topo-order\" in particular looks pointless, and just slows things \ndown.\n\nThe default ordering from git-rev-list (and all other revision listing \nthings, ie \"git log\" etc) _does_ guarantee that we never show a child \nbefore _one_ of its parents has been shown (although \"parent\" in this case \nmay be the command line).\n\nAs such, \"--max-count=1 --topo-order\" is pointless if you only give one \nrevision, because whether you use --topo-order or not, the first commit \nwill always be the parent of all subsequent commits.\n\nSo --topo-order just makes things MUCH MUCH slower with no upsides.\n\nBut that thing is doubly strange, because it uses \".\" as a path specifier. \nIf this is done in the top-most directory, that should mean \"all changes\", \nwhich in turn means that the whole thing should be equivalent to\n\n\tgit rev-parse \"$1^0\"\n\nsince all commits should make _some_ change, and thus the first revision \nin the list should always be the top commit - the one you passed in as an \nargument.\n\n\t\t\tLinus\n"},{"id":"23792","messageId":"Pine.LNX.4.64.0607131806140.5623@g5.osdl.org","threadId":"4878","inReplyTo":"1152838562.31372.58.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T01:08:44Z","receivedAt":"2006-07-14T01:08:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Jul 2006, David Woodhouse wrote:\n>\n> Btw, git-rev-list is _very_ slow at this. Even when the output is\n> actually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:\n> \n> pmac /pmac/git/linux-2.6 $ git-rev-parse HEAD\n> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\n> pmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include\n> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\n> \n> real    0m18.840s\n> \n> Is there a better way to do that step?\n\nUmm.. On my poor little 1.6GHz laptop:\n\n\t[torvalds@evo linux]$ time git-rev-list --max-count=1 HEAD -- include\n\tab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\n\n\treal    0m0.014s\n\tuser    0m0.004s\n\tsys     0m0.012s\n\nthat's 0.014 sec. Not exactly slow.\n\nNow, the --topo-order you have there does slow it down a lot:\n\n\t[torvalds@evo linux]$ time git-rev-list --max-count=1 --topo-order HEAD -- include\n\tab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a\n\n\treal    0m24.016s\n\tuser    0m23.973s\n\tsys     0m0.016s\n\nso now it takes 24 seconds, and gives the same result.\n\n\t\tLinus\n"},{"id":"23793","messageId":"1152840456.31372.75.camel@shinybook.infradead.org","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607131800520.5623@g5.osdl.org","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T01:27:35Z","receivedAt":"2006-07-14T01:27:35Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-07-13 at 18:05 -0700, Linus Torvalds wrote:\n> \n> On Thu, 13 Jul 2006, Junio C Hamano wrote:\n> > \n> > I am not sure what function incparent() is trying to do with\n> > this:\n> > \n> > \tgit rev-list --max-count=1 --topo-order $1 -- .\n> \n> Yeah, that looks strange.\n> \n> The \"--topo-order\" in particular looks pointless, and just slows things \n> down.\n> \n> The default ordering from git-rev-list (and all other revision listing \n> things, ie \"git log\" etc) _does_ guarantee that we never show a child \n> before _one_ of its parents has been shown (although \"parent\" in this case \n> may be the command line).\n\nDoes it? I thought at one point it sorted on some random criterion like\nalphabetically by author, or some other cosmetic information which isn't\nreally part of the git structure -- like the timestamp or something?\nWe still don't enforce monotonicity, do we? The timestamps are still\njust fluff?\n\n> But that thing is doubly strange, because it uses \".\" as a path specifier. \n> If this is done in the top-most directory, that should mean \"all changes\", \n> which in turn means that the whole thing should be equivalent to\n> \n> \tgit rev-parse \"$1^0\"\n> \n> since all commits should make _some_ change, and thus the first revision \n> in the list should always be the top commit - the one you passed in as an \n> argument.\n\nIn this case, I really do have commits in the intermediate tree which\ndon't actually change anything, and I want to filter them out -- I\ncouldn't see a simple way to do it all in one pass.\n\n-- \ndwmw2\n"},{"id":"23795","messageId":"7vwtagsyi0.fsf@assigned-by-dhcp.cox.net","threadId":"4878","inReplyTo":"1152838562.31372.58.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-14T02:37:11Z","receivedAt":"2006-07-14T02:37:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Woodhouse <dwmw2@infradead.org> writes:\n\n> On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:\n>> With modern enough git, you can rewrite\n>>         KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\\  | cut -f1`\n>> with\n>>         KBUILDSHA1=`git rev-parse $TREE:Kbuild`\n>\n>\n> Aha. Thanks.\n>\n>> I am not sure what function incparent() is trying to do with\n>> this:\n>> \n>>         git rev-list --max-count=1 --topo-order $1 -- . \n>\n> Find the latest ancestor commit which actually changed any files. The\n> first script has a similar line, except that it finds the latest\n> ancestor which changed anything in include/\n>\n> Consider a kernel tree with commits A-->B-->C-->D, of which only A and C\n> change anything in include/ and in fact only C actually changes the\n> _exported_ headers after the unifdef and sed bits. \n>\n> The first script (extract-khdrs-git.sh) creates a 'stage1' branch which\n> only contains commits A'-->C', with the _exported_ header tree for each.\n>\n> The second script (extract-khdrs-stage2.sh) then creates the master\n> branch with the same tree objects, but omitting the commits which don't\n> change anything. So it contains only commit C''\n\nI guess what I was getting at was if you can avoid creating\ncommits that do not change anything from previous in stage1\nbranch, you do not have to do this, but I haven't studied stage1\nscript deeply enough.\n"},{"id":"23799","messageId":"Pine.LNX.4.64.0607132157370.5623@g5.osdl.org","threadId":"4878","inReplyTo":"1152840456.31372.75.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T05:16:53Z","receivedAt":"2006-07-14T05:16:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Jul 2006, David Woodhouse wrote:\n> > \n> > The default ordering from git-rev-list (and all other revision listing \n> > things, ie \"git log\" etc) _does_ guarantee that we never show a child \n> > before _one_ of its parents has been shown (although \"parent\" in this case \n> > may be the command line).\n> \n> Does it? I thought at one point it sorted on some random criterion like\n> alphabetically by author, or some other cosmetic information which isn't\n> really part of the git structure -- like the timestamp or something?\n> We still don't enforce monotonicity, do we? The timestamps are still\n> just fluff?\n\nThe timestamps are, and always have been, just a heuristic.\n\nThe output order of git-rev-list is actually entirely well-defined, but \nit's the _cheap_ ordering, not the strict and full topological one.\n\nThe cheap ordering means that we don't ever look at the whole history, but \nit's still a real \"DAG reachability ordering\" in the sense that when we \noutput a commit, we have _always_ output _one_ full path of commits to \nreach that commit from one of the starting point.\n\nBut since you can traverse the DAG in any number of ways, the heuristic is \nthat when there are multiple choices, we pick the one with the most recent \ncommit date.\n\nSo to give an example, let's say we have\n\n\tHEAD  ->     A\n\t\t    / \\\n\t\t   B   C\n\t\t  / \\   \\\n\t\t D   E   F\n\t\t  \\ /   / \\\n\t\t   G   H  I\n\t\t  .......\n\nthe difference between --topo-order and the default ordering for\n\n\tgit rev-list HEAD\n\nis most visible for commit 'G'.\n\nFor --topo-order, we guarantee that before we show 'G', we _will_ have \nshown both 'D' and 'E'. In other words, --topo-ordering guarantees that it \nshows _all_ children before it shows the parent.\n\nThat's a _very_ very expensive thing to guarantee, because you can't \nactually tell that you've seen all children on 'G' before you've basically \ntraversed most of the tree. In the above example, you CANNOT tell whether \n'F' is a child of 'G', for exmaple. Think about it. You don't know - maybe \nthe missing piece is 'I' -> 'Z' -> 'G', but without having parsed all the \ncommits, you'll never know.\n\n[ Actually, strictly speaking, you can guarantee it earlier than before \n  you parsed them _all_: you can guarantee it once _every_single_commit_ \n  whose parents you haven't followed yet is a direct ancestor of 'G' - at \n  that point, and not before, do you know that 'G' can have no more \n  children. That's actually very expensive to compute, so we don't do it - \n  we will walk the whole history, and only _then_ do we use one of the \n  algorithms to generate a topological sort from the full DAG.\n\n  If somebody knows of an _incremental_ algorithm that doesn't need the \n  full DAG and can do a topo-ordering, that would be wonderful. But it's \n  basically very very very expensive. ]\n\nSo by default, we don't do that at all. By default, we will print out 'G' \nwhenever we have printed out _any_ path leading to 'G', and 'G' is the \ncommit with the most recent commit date.\n\nSo we might print things out as A, B, D, G, E ... - notice how we printed \nout 'E' _after_ we did 'G', but we did have the A->B->D->G path, so G was \nreachable from the top along the path we printed.\n\n> In this case, I really do have commits in the intermediate tree which\n> don't actually change anything, and I want to filter them out -- I\n> couldn't see a simple way to do it all in one pass.\n\nOk, in that case, the \".\" is correct, but the --topo-order should be \nunnecessary because you only care about the first entry.\n\n\t\t\tLinus\n"},{"id":"23804","messageId":"Pine.LNX.4.64.0607132251310.5623@g5.osdl.org","threadId":"4878","inReplyTo":"1152840456.31372.75.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T05:52:34Z","receivedAt":"2006-07-14T05:52:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Jul 2006, David Woodhouse wrote:\n> \n> > But that thing is doubly strange, because it uses \".\" as a path specifier. \n> > If this is done in the top-most directory, that should mean \"all changes\", \n> > which in turn means that the whole thing should be equivalent to\n> > \n> > \tgit rev-parse \"$1^0\"\n> > \n> > since all commits should make _some_ change, and thus the first revision \n> > in the list should always be the top commit - the one you passed in as an \n> > argument.\n> \n> In this case, I really do have commits in the intermediate tree which\n> don't actually change anything, and I want to filter them out -- I\n> couldn't see a simple way to do it all in one pass.\n\nBtw, I'm actually surprised that my path simplification didn't filter out \nthe \".\" and make it mean exactly the same as not giving a path at all. I \nthought I had done that earlier, but if you say \"-- .\" matters, then it \nobviously does..\n\n\t\tLinus\n"},{"id":"23806","messageId":"1152861620.6977.3.camel@insmouth","threadId":"4878","inReplyTo":"1152835150.31372.23.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Ian Campbell","fromEmail":"ijc@hellion.org.uk","sentAt":"2006-07-14T07:20:19Z","receivedAt":"2006-07-14T07:20:19Z","isPatch":false,"sender":{"key":"ijc@hellion.org.uk","avatar":"https://avatars.githubusercontent.com/u/12985729?v=4"},"body":"On Fri, 2006-07-14 at 00:59 +0100, David Woodhouse wrote:\n> At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git\n> there's a git tree which contains the sanitised exported headers for all\n> architectures -- basically the result of 'make headers_install'.\n> \n> It tracks Linus' kernel tree, by means of some evil scripts.¹\n> \n> Only commits in Linus' tree which actually affect the exported result\n> should have an equivalent commit in the above tree, which means that any\n> changes which affect userspace should be clearly visible for review.\n\nIt might be useful to append the commit checksum from Linus' tree to the\ncomments so it is easier to backtrack to the original commit.\n\nIan. \n-- \nIan Campbell\n\nYour step will soil many countries.\n"},{"id":"23807","messageId":"7vy7uwr5cl.fsf@assigned-by-dhcp.cox.net","threadId":"4878","inReplyTo":"1152861620.6977.3.camel@insmouth","subject":"Re: Kernel headers git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-14T07:52:10Z","receivedAt":"2006-07-14T07:52:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ian Campbell <ijc@hellion.org.uk> writes:\n\n> It might be useful to append the commit checksum from Linus' tree to the\n> comments so it is easier to backtrack to the original commit.\n\nAlthough I am not a kernel person, I can imagine how that would\nbe useful.\n\nThe pre-generated documentation branches in git.git repository\nare managed similarly to allow tracking of the branch they\noriginate from.\n"},{"id":"23808","messageId":"1152869915.3191.12.camel@pmac.infradead.org","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607132251310.5623@g5.osdl.org","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T09:38:35Z","receivedAt":"2006-07-14T09:38:35Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-07-13 at 22:52 -0700, Linus Torvalds wrote:\n> Btw, I'm actually surprised that my path simplification didn't filter out \n> the \".\" and make it mean exactly the same as not giving a path at all. I \n> thought I had done that earlier, but if you say \"-- .\" matters, then it \n> obviously does..\n\nIn this specific case where I have a whole bunch of commits which don't\nactually change anything, it definitely does make a difference...\n\nhera /home/dwmw2 $ export GIT_DIR=/pub/scm/linux/kernel/git/dwmw2/kernel-headers.git\nhera /home/dwmw2 $ git-rev-list --max-count=5 stage1\ne4e2fcc2c333aac5f6331c1df256ff28d7ee76d7\n32ca8021c5ab7b9d44e8a08aeb53e52af5223fec\n6b8380885464e069ae22e1e04f4a905c9e918f4e\n2dee58696cab32506f655cb94a63cf4b18a13b37\n402429bc9ac5eb891f253f6dae1228338f7f0ea5\nhera /home/dwmw2 $ git-rev-list --max-count=5 stage1 -- .\nd1aba9314210d616cd2aa9ee91176c1dba6d3834\n0b627fd403d6319fe50fbd8b95d5ea02017731fa\nb29cfa21bbdfc25271ef446b9df94ed8b5425711\ne2407b6a9a643b378700474c9079dd8620e820ed\nc0df084d3e2ec0df6dafda8099e7c27c29760843\n\nJunio is right -- if I can avoid creating commits that don't change any\nfiles in the stage1 branch, then I don't have to do this. That would be\n_hard_ though...\n\nCurrently, the selection of commits from your original tree to be\nrepresented in the stage1 branch is simple -- it's \"those commits which\ntouch include/\". And 'rev-list -- include'  works nicely for that.\n\nYet what I actually want in the final result is \"those commits which\nchange the result of the _exported_ headers\". It's slightly less\nrealistic to want rev-list to find that for me directly from the\noriginal kernel tree without having done the export step in stage1 --\nwhat I need to do is create the exported header tree for each commit\nwhich _might_ change it, then filter out the commits which don't\n_actually_ change it.\n\nThe extra commits in the stage1 branch are cheap enough -- by definition\nthey don't lead to any extra tree or blob objects. I think the two-stage\nexport is probably the best approach, unless I'm missing something.\n\n-- \ndwmw2\n"},{"id":"23809","messageId":"1152872626.3191.56.camel@pmac.infradead.org","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607132157370.5623@g5.osdl.org","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T10:23:46Z","receivedAt":"2006-07-14T10:23:46Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:\n> So to give an example, let's say we have\n> \n>         HEAD  ->     A\n>                     / \\\n>                    B   C\n>                   / \\   \\\n>                  D   E   F\n>                   \\ /   / \\\n>                    G   H  I\n>                   .......\n> \n> the difference between --topo-order and the default ordering for\n> \n>         git rev-list HEAD\n> \n> is most visible for commit 'G'.\n> \n> For --topo-order, we guarantee that before we show 'G', we _will_ have \n> shown both 'D' and 'E'. In other words, --topo-ordering guarantees that it \n> shows _all_ children before it shows the parent.\n\nAh, OK. Then it should probably be fine. I'll talk myself through it...\n\nWe're building a parallel graph of commits, containing a _subset_ of the\ncommits in the master tree -- only those which touch certain files. \n\nFor each 'interesting' commit X, we create a corresponding commit X' in\nthe slave tree -- we create the corresponding tree object, and we also\nrecursively create its parent commits -- replacing each parent in the\noriginal commit X with the slave-tree equivalent of the closest\n_interesting_ ancestor commit. It's that \"closest interesting ancestor\"\nwhich we're finding with the 'rev-list --max-count-1 -- myfile'\ninvocation. \n\nThe extract-khdrs-stage2.sh script is a simple example of this, and\ndiffers from the other script mostly in the way that it creates the\n_tree_ objects.\n\nSo working from your example above, and assuming that only commits I and\nE actually change the files we care about. This means that merges A, B\nand F are _also_ going to show up in the output of 'rev-list -- myfile'.\n\nSo the slave tree will look like this:\n\n        A'\n       / \\\n      B'  F'\n      |   |\n      E'  I'\n\nThe interesting case, if I'm trying to convince myself that my 'slave'\ntree is always going to have the correct topology, is when a merge\ncommit is _missing_ from the rev-list output -- for example, if commits\nD and E in your original tree both make the _same_ change, then I\nbelieve that the merge commit B will no longer show up, because 'myfile'\nis identical in B and in both of its parents.\n\nIn that case, we accept that the representation isn't going to be\nperfect -- the left-hand parent of A' is going to appear to be _either_\nD' or E', but not B'. In fact, since D' and E' are _identical_ as far as\nwe're concerned, it doesn't really matter which is chosen. The other one\nof the two becomes an unused branch with no children -- we end up with a\ngraph looking like this. \n\n      A'\n     / \\\nD'  E'  F'\n  \\/    |\n        I'\n\n... and the parent of D' and E' is the closest ancestor of G which\nactually touches the files we care about, of course.\n\nAll we care about, in this case, is that the first commit listed by\nrev-list is _either_ D or E, and not something further down the tree.\nAnd that's obviously true from your description of the 'weak ordering',\nso yes -- it does look like I can drop the '--topo-order'. Thanks.\n\n(It would actually be quite nice if I _could_ find a cheap way to\ninclude commit B' in that final example, but it's such a rare case and\nit would be so expensive to do it that I don't think it's worth\npursuing.)\n\n-- \ndwmw2\n"},{"id":"23819","messageId":"Pine.LNX.4.64.0607140828250.5623@g5.osdl.org","threadId":"4878","inReplyTo":"1152869915.3191.12.camel@pmac.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T15:39:24Z","receivedAt":"2006-07-14T15:39:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Jul 2006, David Woodhouse wrote:\n> On Thu, 2006-07-13 at 22:52 -0700, Linus Torvalds wrote:\n> > Btw, I'm actually surprised that my path simplification didn't filter out \n> > the \".\" and make it mean exactly the same as not giving a path at all. I \n> > thought I had done that earlier, but if you say \"-- .\" matters, then it \n> > obviously does..\n> \n> In this specific case where I have a whole bunch of commits which don't\n> actually change anything, it definitely does make a difference...\n\nYes, I'm looking at \"get_pathspec()\", and noting that it really isn't able \nto optimize away the \".\".\n\nIt does turn it into an empty string (which is correct - git internally \ndoes _not_ ever understand the notion of \".\" as the current working \ndirectory), but it doesn't ever do the optimization of noticing that a \npathspec that consists solely of an empty string is \"equivalent\" to an \nempty pathspec.\n\nWhich is exactly what you _want_ in this case, of course, but maybe we \nshould add a test-case for that, so that we never do that trivial \noptimization by mistake.\n\nMaybe something like\n\n\tgit init-db\n\techo Hello > a\n\tgit add a\n\tgit commit -m \"Initial commit\" a\n\nand then:\n\n\tcommit=$(echo \"Unchanged tree\" | git-commit-tree \"HEAD^{tree}\" -p HEAD)\n\tgit-rev-list $commit | wc -l \n\tgit-rev-list $commit -- . | wc -l\n\nwhere the first git-rev-list should return 2, and the second one should \nreturn 1.\n\nAnybody want to write that as a test, verify it, and send Junio a patch?\n\n\t\tLinus\n"},{"id":"23822","messageId":"Pine.LNX.4.64.0607140843570.5623@g5.osdl.org","threadId":"4878","inReplyTo":"1152872626.3191.56.camel@pmac.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T15:57:59Z","receivedAt":"2006-07-14T15:57:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Jul 2006, David Woodhouse wrote:\n\n> On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:\n> > \n> >         HEAD  ->     A\n> >                     / \\\n> >                    B   C\n> >                   / \\   \\\n> >                  D   E   F\n> >                   \\ /   / \\\n> >                    G   H  I\n> >                   .......\n> > \n> \n> So working from your example above, and assuming that only commits I and\n> E actually change the files we care about. This means that merges A, B\n> and F are _also_ going to show up in the output of 'rev-list -- myfile'.\n\nNot necessarily.\n\n> So the slave tree will look like this:\n> \n>         A'\n>        / \\\n>       B'  F'\n>       |   |\n>       E'  I'\n\nYes, but ONLY IF the following is true: A is different from _both_ F and B \nin the relevant files.\n\nIf A == F (in those files), then the A merge will have been simplified \naway. Strictly speaking, what happens is that when it sees the merge A \n(which has parents B and C), and sees that _all_ the changes came from C, \nthe simplification will decide that B simply isn't even interesting, and \nrewrite the merge A as having _only_ C as a parent, since C clearly \nexplains everything that happened to those files, and B had nothing to do \nwith it.\n\nIt will then remove both A (which is no longer a merge) and C, since \nneither of them change the files, and will leave you with just\n\n\tF'\n\t|\n\tI'\n\ninstead.\n\n> The interesting case, if I'm trying to convince myself that my 'slave'\n> tree is always going to have the correct topology, is when a merge\n> commit is _missing_ from the rev-list output\n\nNote that there are only two ways you can be missing a merge:\n - you literally asked for it with \"--no-merges\"\n - the merge had one parent that was identical to it, and the merge was \n   simplified as above.\n\n> In that case, we accept that the representation isn't going to be\n> perfect -- the left-hand parent of A' is going to appear to be _either_\n> D' or E', but not B'. In fact, since D' and E' are _identical_ as far as\n> we're concerned, it doesn't really matter which is chosen. The other one\n> of the two becomes an unused branch with no children -- we end up with a\n> graph looking like this. \n> \n>       A'\n>      / \\\n> D'  E'  F'\n>   \\/    |\n>         I'\n\nYou will never see this, because D' is simply not reachable. You can have \neither:\n\n - A got simplified away as a merge entirely, because C was identical, and \n   B was thus considered \"uninteresting\" (as in \"it not matter for the \n   end result\"), and then the later phase will always remove A too (since, \n   by definition, for the merge to be simplified to a non-merge, it must \n   be identical to the parent it was simplified to have)\n\n - or _both_ B and C were different to A in those files, and A still \n   exists as a merge, but B was identical to one of its parents (let's say \n   E), and was first simplified to \"B->E->G\", and then because B and E \n   were identical, B itself was dropped, and only\n\n\t  A'\n\t / \\\n\tE'  F'\n\t|   |\n\tG'  I'\n\nremains.\n\nNOTE NOTE NOTE! This is how \"git rev-list\" (and all the other related git \ntools, like \"git log\" etc) simplify the tree. It is, in my opinion, the \nonly sane way to do it, although you can pass in \"--full-history\" to say \nthat you don't want any merge simplification at all.\n\nThe reason I mention it is that _your_ simplifications may obviously do \nsomething else entirely, and you may obviously have different rules for \nhow you simplify the tree further. But it sounds like you don't simplify \nthe history at all (apart from the simplification that git-rev-list did \nfor you)?\n\n\t\t\tLinus\n"},{"id":"23827","messageId":"Pine.LNX.4.64.0607141256170.9789@iabervon.org","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607140843570.5623@g5.osdl.org","subject":"Re: Kernel headers git tree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-07-14T17:51:59Z","receivedAt":"2006-07-14T17:51:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 14 Jul 2006, Linus Torvalds wrote:\n\n> On Fri, 14 Jul 2006, David Woodhouse wrote:\n> \n> > On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:\n> > > \n> > >         HEAD  ->     A\n> > >                     / \\\n> > >                    B   C\n> > >                   / \\   \\\n> > >                  D   E   F\n> > >                   \\ /   / \\\n> > >                    G   H  I\n> > >                   .......\n> > > \n> > \n> > So working from your example above, and assuming that only commits I and\n> > E actually change the files we care about. This means that merges A, B\n> > and F are _also_ going to show up in the output of 'rev-list -- myfile'.\n> \n> Not necessarily.\n> \n> > So the slave tree will look like this:\n> > \n> >         A'\n> >        / \\\n> >       B'  F'\n> >       |   |\n> >       E'  I'\n> \n> Yes, but ONLY IF the following is true: A is different from _both_ F and B \n> in the relevant files.\n\nActually, this is an unlikely result, because B' and F' wouldn't appear \nunless they either have multiple children that appear or they have new\nmodifications made to the files during the merge.\n\nThe result under the conditions that the only changes are in E and I is:\n\n   A'\n  / \\\n E'  I'\n\nWhich, of course, is what you should expect: it only includes E, I, and \nmerges which create a novel combination of changes (even if the changes \nthey include have appeared alone before).\n\n> NOTE NOTE NOTE! This is how \"git rev-list\" (and all the other related git \n> tools, like \"git log\" etc) simplify the tree. It is, in my opinion, the \n> only sane way to do it, although you can pass in \"--full-history\" to say \n> that you don't want any merge simplification at all.\n> \n> The reason I mention it is that _your_ simplifications may obviously do \n> something else entirely, and you may obviously have different rules for \n> how you simplify the tree further. But it sounds like you don't simplify \n> the history at all (apart from the simplification that git-rev-list did \n> for you)?\n\nIt seems like we ought to be able to provide the simplification procedure \nto code that's done further filtering on the set of commits somehow, or \nprovide a framework with a callback, but it's a non-trivial design.\n\nI think that a program to generate a slave git tree based in some \nuser-modifiable way on a parent repository would be useful and \nimplementable. I'd thought a bunch about it a while ago, for extracting \nseparable parts of projects (e.g., make a kbuild project that's pulled out \nof the kernel tree, but is still a regular git project to anyone who \ndoesn't know this). My conclusion was that you need a cache of mappings, \nbecause otherwise you can't identify that you already have a transformed \nversion of a commit, because you don't know its transformed parents, \nunless you've gone all the way back to the root (which doesn't have \nparents). But I think a \"git2git\" script wouldn't be any harder than the \nother import scripts, and would solve this problem nicely.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"23828","messageId":"1152899889.3191.71.camel@pmac.infradead.org","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607141256170.9789@iabervon.org","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T17:58:09Z","receivedAt":"2006-07-14T17:58:09Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2006-07-14 at 13:51 -0400, Daniel Barkalow wrote:\n> I think that a program to generate a slave git tree based in some \n> user-modifiable way on a parent repository would be useful and \n> implementable. I'd thought a bunch about it a while ago, for extracting \n> separable parts of projects (e.g., make a kbuild project that's pulled out \n> of the kernel tree, but is still a regular git project to anyone who \n> doesn't know this). My conclusion was that you need a cache of mappings, \n> because otherwise you can't identify that you already have a transformed \n> version of a commit, because you don't know its transformed parents, \n> unless you've gone all the way back to the root (which doesn't have \n> parents).\n\nAbsolutely. You don't want to go all the way back to the root every time\n-- it's an incremental process, and you have to cache the mappings from\nobjects in the 'master' tree to objects in the 'slave' tree.\n\nMy existing scripts already do that part -- I didn't think it was worth\ncommenting on.\n\nhttp://david.woodhou.se/extract-jffs2-git.sh\nhttp://david.woodhou.se/extract-khdrs-git.sh\nhttp://david.woodhou.se/extract-khdrs-stage2.sh\n\nAnd no, I don't do any further simplification of the graph of commits\nother than what 'git-rev-list' does for me. I need to fully go over\nLinus' last mail and understand it, but I think the conclusion is that\nthe above scripts are fine, and I can happily drop --topo-order from\nthem.\n\n-- \ndwmw2\n"},{"id":"23829","messageId":"7v64i0qd4d.fsf@assigned-by-dhcp.cox.net","threadId":"4878","inReplyTo":"1152869915.3191.12.camel@pmac.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-14T18:01:54Z","receivedAt":"2006-07-14T18:01:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Woodhouse <dwmw2@infradead.org> writes:\n\n> Yet what I actually want in the final result is \"those commits which\n> change the result of the _exported_ headers\". It's slightly less\n> realistic to want rev-list to find that for me directly from the\n> original kernel tree without having done the export step in stage1 --\n> what I need to do is create the exported header tree for each commit\n> which _might_ change it, then filter out the commits which don't\n> _actually_ change it.\n>\n> The extra commits in the stage1 branch are cheap enough -- by definition\n> they don't lead to any extra tree or blob objects. I think the two-stage\n> export is probably the best approach, unless I'm missing something.\n\nSince you are not building an exact parallel history with the\nsame topology (you are trying to cull the commits in the new\ntree that do not change the resulting header files), I do not\nsee much point in the parent conversion loop in the first script\nto compute CONVERTEDPARENTS.\n\nHow about making it simpler?\n\n\t* Keep the current HEAD of the \"headers\" branch at in\n          refs/heads/kernel-headers\n\n\t* Whenever you see $UPSTREAM_GITDIR/refs/heads/master\n          changes, you do your converttree to come up with the\n          new header tree\n\n\t* See if the resulting tree changed by doing something\n          like this:\n\n                TREE=`converttree $INCDIR $KBUILDASMSHA`\n                case \"`git diff-tree --name-only kernel-headers $TREE`\" in\n                '')\n                        # No changes in the result\n                        exit\n                esac\n\n\t  Stop processing here if there is no change.\n\n\t* Make a new commit, with its parent set to the current\n          value of refs/heads/kernel-headers, perhaps with the\n          same message as $UPSTREAM_GITDIR/refs/heads/master\n          has as you do already.\n\n\t* Advance refs/heads/kernel-headers only when you\n          actually make a new commit.\n\nI would further suggest to record the value of the upstream\ncommit object name, $UPSTREAM_GITDIR/refs/heads/master,\nsomewhere in the commit message, by using \"git describe\".  This\nwill help people who use your converted headers to know which\nreleased version of the Linus kernel the headers correspond to,\nand also help you notice when the upstream is updated during the\nnext run.\n"},{"id":"23830","messageId":"200607142005.36998.ioe-lkml@rameria.de","threadId":"4878","inReplyTo":"1152835150.31372.23.camel@shinybook.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Ingo Oeser","fromEmail":"ioe-lkml@rameria.de","sentAt":"2006-07-14T18:05:35Z","receivedAt":"2006-07-14T18:05:35Z","isPatch":false,"sender":{"key":"ioe-lkml@rameria.de","avatar":null},"body":"Hi David,\n\nOn Friday, 14. July 2006 01:59, David Woodhouse wrote:\n> Only commits in Linus' tree which actually affect the exported result\n> should have an equivalent commit in the above tree, which means that any\n> changes which affect userspace should be clearly visible for review.\n\nWhere can I subscribe for commit messages there?\n\nEvery serious systems programmer (for Linux) will ask this question soon :-)\n\nMaybe one of the Postmasters at vger.kernel.org can setup \na mailing list for this.\n\n\nRegards\n\nIngo Oeser, happy to see this project finally there\n"},{"id":"23831","messageId":"1152900971.3191.76.camel@pmac.infradead.org","threadId":"4878","inReplyTo":"200607142005.36998.ioe-lkml@rameria.de","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T18:16:11Z","receivedAt":"2006-07-14T18:16:11Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2006-07-14 at 20:05 +0200, Ingo Oeser wrote:\n> Hi David,\n> \n> On Friday, 14. July 2006 01:59, David Woodhouse wrote:\n> > Only commits in Linus' tree which actually affect the exported result\n> > should have an equivalent commit in the above tree, which means that any\n> > changes which affect userspace should be clearly visible for review.\n> \n> Where can I subscribe for commit messages there?\n\nWell, they're all derived from commits in Linus' tree. I could set up\nanother mailing list feed script which tracks it, but I'd like to give\nit a while (until I'm happy with the export scripts) first.\n\n-- \ndwmw2\n"},{"id":"23832","messageId":"1152901280.3191.82.camel@pmac.infradead.org","threadId":"4878","inReplyTo":"7v64i0qd4d.fsf@assigned-by-dhcp.cox.net","subject":"Re: Kernel headers git tree","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T18:21:20Z","receivedAt":"2006-07-14T18:21:20Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2006-07-14 at 11:01 -0700, Junio C Hamano wrote:\n> David Woodhouse <dwmw2@infradead.org> writes:\n> \n> > Yet what I actually want in the final result is \"those commits which\n> > change the result of the _exported_ headers\". It's slightly less\n> > realistic to want rev-list to find that for me directly from the\n> > original kernel tree without having done the export step in stage1 --\n> > what I need to do is create the exported header tree for each commit\n> > which _might_ change it, then filter out the commits which don't\n> > _actually_ change it.\n> >\n> > The extra commits in the stage1 branch are cheap enough -- by definition\n> > they don't lead to any extra tree or blob objects. I think the two-stage\n> > export is probably the best approach, unless I'm missing something.\n> \n> Since you are not building an exact parallel history with the\n> same topology (you are trying to cull the commits in the new\n> tree that do not change the resulting header files), I do not\n> see much point in the parent conversion loop in the first script\n> to compute CONVERTEDPARENTS.\n> \n> How about making it simpler?\n> \n> \t* Keep the current HEAD of the \"headers\" branch at in\n>           refs/heads/kernel-headers\n> \n> \t* Whenever you see $UPSTREAM_GITDIR/refs/heads/master\n>           changes, you do your converttree to come up with the\n>           new header tree\n> \n> \t* See if the resulting tree changed by doing something\n>           like this:\n> \n>                 TREE=`converttree $INCDIR $KBUILDASMSHA`\n>                 case \"`git diff-tree --name-only kernel-headers $TREE`\" in\n>                 '')\n>                         # No changes in the result\n>                         exit\n>                 esac\n> \n> \t  Stop processing here if there is no change.\n> \n> \t* Make a new commit, with its parent set to the current\n>           value of refs/heads/kernel-headers, perhaps with the\n>           same message as $UPSTREAM_GITDIR/refs/heads/master\n>           has as you do already.\n> \n> \t* Advance refs/heads/kernel-headers only when you\n>           actually make a new commit.\n\nUnless I'm misunderstanding, I then don't get a tree with a topology\nwhich matches Linus' tree -- I just get a series of snapshots, and it's\ndependent on the timing of my cron jobs.\n\nThat means that there isn't a 1:1 relationship between any commit in the\nslave tree and a corresponding commit in the upstream tree, and that the\nslave tree can't (sensibly) be reproduced.\n\nI'd much rather keep it the way it is -- but I'm certainly interested in\nways that I could simplify the process of generating what I have at the\nmoment.\n\n> I would further suggest to record the value of the upstream\n> commit object name, $UPSTREAM_GITDIR/refs/heads/master,\n> somewhere in the commit message, by using \"git describe\".  This\n> will help people who use your converted headers to know which\n> released version of the Linus kernel the headers correspond to,\n> and also help you notice when the upstream is updated during the\n> next run.\n\nYeah, that was already suggested. I'll do that.\n\n-- \ndwmw2\n"},{"id":"23833","messageId":"Pine.LNX.4.64.0607141402520.9789@iabervon.org","threadId":"4878","inReplyTo":"1152899889.3191.71.camel@pmac.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-07-14T18:21:51Z","receivedAt":"2006-07-14T18:21:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 14 Jul 2006, David Woodhouse wrote:\n\n> And no, I don't do any further simplification of the graph of commits\n> other than what 'git-rev-list' does for me. I need to fully go over\n> Linus' last mail and understand it, but I think the conclusion is that\n> the above scripts are fine, and I can happily drop --topo-order from\n> them.\n\nI think the mechanism you're using is fine, but it's also generally \nuseful, and it would be nice to have the generic part split out from the \nparticular application. Also, those scripts really are as evil as \nadvertized, and using more of the git programs would make that a lot \nsaner.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"23913","messageId":"20060717223432.GA25522@steel.home","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607140828250.5623@g5.osdl.org","subject":"[PATCH] Trivial path optimization test","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-17T22:34:32Z","receivedAt":"2006-07-17T22:34:32Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Fri, Jul 14, 2006 17:39:24 +0200:\n> > > Btw, I'm actually surprised that my path simplification didn't filter out\n> > > the \".\" and make it mean exactly the same as not giving a path at all. I\n> > > thought I had done that earlier, but if you say \"-- .\" matters, then it\n> > > obviously does..\n> >\n> > In this specific case where I have a whole bunch of commits which don't\n> > actually change anything, it definitely does make a difference...\n> \n> Yes, I'm looking at \"get_pathspec()\", and noting that it really isn't able\n> to optimize away the \".\".\n> \n> It does turn it into an empty string (which is correct - git internally\n> does _not_ ever understand the notion of \".\" as the current working\n> directory), but it doesn't ever do the optimization of noticing that a\n> pathspec that consists solely of an empty string is \"equivalent\" to an\n> empty pathspec.\n> \n> Which is exactly what you _want_ in this case, of course, but maybe we\n> should add a test-case for that, so that we never do that trivial\n> optimization by mistake.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\n...\n> Anybody want to write that as a test, verify it, and send Junio a patch?\n>\n>                Linus\n\nSo here it is.\n\n t/t6004-rev-list-path-optim.sh |   19 +++++++++++++++++++\n 1 files changed, 19 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t6004-rev-list-path-optim.sh b/t/t6004-rev-list-path-optim.sh\nnew file mode 100755\nindex 0000000..5182dbb\n--- /dev/null\n+++ b/t/t6004-rev-list-path-optim.sh\n@@ -0,0 +1,19 @@\n+#!/bin/sh\n+\n+test_description='git-rev-list trivial path optimization test'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+echo Hello > a &&\n+git add a &&\n+git commit -m \"Initial commit\" a\n+'\n+\n+test_expect_success path-optimization '\n+    commit=$(echo \"Unchanged tree\" | git-commit-tree \"HEAD^{tree}\" -p HEAD) &&\n+    test $(git-rev-list $commit | wc -l) = 2 &&\n+    test $(git-rev-list $commit -- . | wc -l) = 1\n+'\n+\n+test_done\n-- \n1.4.1.gb944\n"},{"id":"23926","messageId":"200607182315.03874.ioe-lkml@rameria.de","threadId":"4878","inReplyTo":"1152900971.3191.76.camel@pmac.infradead.org","subject":"Re: Kernel headers git tree","fromName":"Ingo Oeser","fromEmail":"ioe-lkml@rameria.de","sentAt":"2006-07-18T21:15:02Z","receivedAt":"2006-07-18T21:15:02Z","isPatch":false,"sender":{"key":"ioe-lkml@rameria.de","avatar":null},"body":"Hi David,\n\nOn Friday, 14. July 2006 20:16, David Woodhouse wrote:\n> Well, they're all derived from commits in Linus' tree. I could set up\n> another mailing list feed script which tracks it, but I'd like to give\n> it a while (until I'm happy with the export scripts) first.\n\nSounds good :-)\n\n\nThanks & Regards\n\nIngo Oeser\n"},{"id":"24039","messageId":"7v4px7h5df.fsf@assigned-by-dhcp.cox.net","threadId":"4878","inReplyTo":"20060717223432.GA25522@steel.home","subject":"Re: [PATCH] Trivial path optimization test","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-24T06:41:16Z","receivedAt":"2006-07-24T06:41:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clean up the commit log pretty please.\n"},{"id":"24075","messageId":"20060724232303.GB14792@steel.home","threadId":"4878","inReplyTo":"Pine.LNX.4.64.0607140828250.5623@g5.osdl.org","subject":"[PATCH] Trivial path optimization test","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-24T23:23:03Z","receivedAt":"2006-07-24T23:23:03Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"\nLinus:\n    get_pathspec() does turn '.' into an empty string (which is\n    correct - git internally does _not_ ever understand the notion of\n    \".\" as the current working directory), but it doesn't ever do the\n    optimization of noticing that a pathspec that consists solely of\n    an empty string is \"equivalent\" to an empty pathspec.\n\nThe test is to ensure that this behaviour stays.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\n t/t6004-rev-list-path-optim.sh |   19 +++++++++++++++++++\n 1 files changed, 19 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t6004-rev-list-path-optim.sh b/t/t6004-rev-list-path-optim.sh\nnew file mode 100755\nindex 0000000..5182dbb\n--- /dev/null\n+++ b/t/t6004-rev-list-path-optim.sh\n@@ -0,0 +1,19 @@\n+#!/bin/sh\n+\n+test_description='git-rev-list trivial path optimization test'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+echo Hello > a &&\n+git add a &&\n+git commit -m \"Initial commit\" a\n+'\n+\n+test_expect_success path-optimization '\n+    commit=$(echo \"Unchanged tree\" | git-commit-tree \"HEAD^{tree}\" -p HEAD) &&\n+    test $(git-rev-list $commit | wc -l) = 2 &&\n+    test $(git-rev-list $commit -- . | wc -l) = 1\n+'\n+\n+test_done\n-- \n1.4.1.gb944\n"},{"id":"24076","messageId":"20060724232339.GC14792@steel.home","threadId":"4878","inReplyTo":"7v4px7h5df.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Trivial path optimization test","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-24T23:23:39Z","receivedAt":"2006-07-24T23:23:39Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Mon, Jul 24, 2006 08:41:16 +0200:\n> Clean up the commit log pretty please.\n\nNo problem.\n"}]}