{"thread":{"id":"1783","subject":"hmm, can't we give the \"root\" a parent?","startedAt":"2005-09-12T18:11:01Z","lastAt":"2005-09-17T01:22:38Z","messageCount":13,"participants":["Kay Sievers","A Large Angry SCM","Linus Torvalds","Tony Luck"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8404","messageId":"20050912181101.GA22221@vrfy.org","threadId":"1783","inReplyTo":null,"subject":"hmm, can't we give the \"root\" a parent?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-12T18:11:01Z","receivedAt":"2005-09-12T18:11:01Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"Can't we teach the git tools that a \"root commit\" (one without a any\nparent) is not visible as a \"root\", if let's say:\n  .git/parents/<root-commit-id> -> <fake-parent-id>\n\ndoes connect a \"fake\" parent to the \"root\"? This way we could add any\nolder Linux history to the current tree. Combined with \"alternates\" it\ncould live in a complete different repository too.\n\nThanks,\nKay\n"},{"id":"8408","messageId":"Pine.LNX.4.58.0509121123280.3242@g5.osdl.org","threadId":"1783","inReplyTo":"20050912181101.GA22221@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-12T18:26:24Z","receivedAt":"2005-09-12T18:26:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Sep 2005, Kay Sievers wrote:\n>\n> Can't we teach the git tools that a \"root commit\" (one without a any\n> parent) is not visible as a \"root\", if let's say:\n>   .git/parents/<root-commit-id> -> <fake-parent-id>\n> \n> does connect a \"fake\" parent to the \"root\"? This way we could add any\n> older Linux history to the current tree. Combined with \"alternates\" it\n> could live in a complete different repository too.\n\nEhh.. That's exactly what \"grafting\" is about.\n\nSo just do\n\n\techo \"<root-id> <grafted-parent-id>\" >> .git/info/grafts\n\nand it should all work.\n\nOf course, anything that parses the commits by hand won't see it, but all \nthe regular tools hopefully do.\n\n\t\tLinus\n"},{"id":"8407","messageId":"4325C89F.1030406@gmail.com","threadId":"1783","inReplyTo":"20050912181101.GA22221@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-09-12T18:27:43Z","receivedAt":"2005-09-12T18:27:43Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Kay Sievers wrote:\n> Can't we teach the git tools that a \"root commit\" (one without a any\n> parent) is not visible as a \"root\", if let's say:\n>   .git/parents/<root-commit-id> -> <fake-parent-id>\n> \n> does connect a \"fake\" parent to the \"root\"? This way we could add any\n> older Linux history to the current tree. Combined with \"alternates\" it\n> could live in a complete different repository too.\n\nAlready done. Search the following for \"info/grafts\".\n\nhttp://www.kernel.org/pub/software/scm/git/docs/repository-layout.html\n"},{"id":"8415","messageId":"20050912195947.GA28502@vrfy.org","threadId":"1783","inReplyTo":"Pine.LNX.4.58.0509121123280.3242@g5.osdl.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-12T19:59:47Z","receivedAt":"2005-09-12T19:59:47Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Mon, Sep 12, 2005 at 11:26:24AM -0700, Linus Torvalds wrote:\n> On Mon, 12 Sep 2005, Kay Sievers wrote:\n> >\n> > Can't we teach the git tools that a \"root commit\" (one without a any\n> > parent) is not visible as a \"root\", if let's say:\n> >   .git/parents/<root-commit-id> -> <fake-parent-id>\n> > \n> > does connect a \"fake\" parent to the \"root\"? This way we could add any\n> > older Linux history to the current tree. Combined with \"alternates\" it\n> > could live in a complete different repository too.\n> \n> Ehh.. That's exactly what \"grafting\" is about.\n> \n> So just do\n> \n> \techo \"<root-id> <grafted-parent-id>\" >> .git/info/grafts\n> \n> and it should all work.\n> \n> Of course, anything that parses the commits by hand won't see it, but all \n> the regular tools hopefully do.\n\nYup, tried it and works nicely with the history.git tree on kernel.org\nconnected to your tree, replacing the initial commit.\n\nAnd good to know about that, need to fix the \"parent\" link in gitweb to\nrespect grafts.\n\nThanks,\nKay\n"},{"id":"8417","messageId":"Pine.LNX.4.58.0509121316030.3266@g5.osdl.org","threadId":"1783","inReplyTo":"20050912195947.GA28502@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-12T20:21:13Z","receivedAt":"2005-09-12T20:21:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Sep 2005, Kay Sievers wrote:\n>\n> And good to know about that, need to fix the \"parent\" link in gitweb to\n> respect grafts.\n\nNote that the simplest way to do this is to try to use \"git-rev-list\" as \nmuch as possible. The \"--parents\" flag makes the output have the parents \n(automatically _including_ any grafts) on the line that contains the \ncommit ID.\n\nThat's especially true of any tools that use git-rev-list anyway for other\nreasons. Eg \"gitk\" could parse the parent stuff this way, and didn't need\nto know about the info/grafts file at all. I suspect the same should be\ntrue of gitweb.\n\n(So instead of trying to parse the parent info from the header of the \ncommit, just do \"git-rev-list --pretty --parents\" and parse that).\n\n\t\tLinus\n"},{"id":"8423","messageId":"20050912210006.GA32211@vrfy.org","threadId":"1783","inReplyTo":"Pine.LNX.4.58.0509121316030.3266@g5.osdl.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-12T21:00:06Z","receivedAt":"2005-09-12T21:00:06Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Mon, Sep 12, 2005 at 01:21:13PM -0700, Linus Torvalds wrote:\n> On Mon, 12 Sep 2005, Kay Sievers wrote:\n> >\n> > And good to know about that, need to fix the \"parent\" link in gitweb to\n> > respect grafts.\n> \n> Note that the simplest way to do this is to try to use \"git-rev-list\" as \n> much as possible. The \"--parents\" flag makes the output have the parents \n> (automatically _including_ any grafts) on the line that contains the \n> commit ID.\n> \n> That's especially true of any tools that use git-rev-list anyway for other\n> reasons. Eg \"gitk\" could parse the parent stuff this way, and didn't need\n> to know about the info/grafts file at all. I suspect the same should be\n> true of gitweb.\n\nEverthing that walk from one commit to another, uses git-rev-list, sure.\nBut in the commit view, and the commitdiff the \"parent\" link and the parent\nthat is passed to diff is read from the commit itself.\n\n> (So instead of trying to parse the parent info from the header of the \n> commit, just do \"git-rev-list --pretty --parents\" and parse that).\n\nI need only one parent:\n  git-rev-list --parents --max-count=1 <id>\n\nHmm, it's one more exec, but I don't need to look at the grafts file or\nwhatever will make it into git the next time I will look at it. :)\n\nThanks,\nKay\n"},{"id":"8434","messageId":"Pine.LNX.4.58.0509121438150.3266@g5.osdl.org","threadId":"1783","inReplyTo":"20050912210006.GA32211@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-12T21:42:16Z","receivedAt":"2005-09-12T21:42:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Sep 2005, Kay Sievers wrote:\n> \n> Everthing that walk from one commit to another, uses git-rev-list, sure.\n> But in the commit view, and the commitdiff the \"parent\" link and the parent\n> that is passed to diff is read from the commit itself.\n> \n> > (So instead of trying to parse the parent info from the header of the \n> > commit, just do \"git-rev-list --pretty --parents\" and parse that).\n> \n> I need only one parent:\n>   git-rev-list --parents --max-count=1 <id>\n\nWho don't you use that to show the comments too? \n\nSo instead of doing\n\n\tgit-cat-file commit <id>\n\n(or whatever you do), just do\n\n\tgit-rev-list --parents --pretty=raw --max-count=1 <id>\n\nThat way you don't get any extra fork/exec overhead - you get everything \nwith one program.\n\n\t\tLinus\n"},{"id":"8443","messageId":"20050912225032.GA8360@vrfy.org","threadId":"1783","inReplyTo":"Pine.LNX.4.58.0509121438150.3266@g5.osdl.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-12T22:50:32Z","receivedAt":"2005-09-12T22:50:32Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Mon, Sep 12, 2005 at 02:42:16PM -0700, Linus Torvalds wrote:\n> \n> \n> On Mon, 12 Sep 2005, Kay Sievers wrote:\n> > \n> > Everthing that walk from one commit to another, uses git-rev-list, sure.\n> > But in the commit view, and the commitdiff the \"parent\" link and the parent\n> > that is passed to diff is read from the commit itself.\n> > \n> > > (So instead of trying to parse the parent info from the header of the \n> > > commit, just do \"git-rev-list --pretty --parents\" and parse that).\n> > \n> > I need only one parent:\n> >   git-rev-list --parents --max-count=1 <id>\n> \n> Who don't you use that to show the comments too? \n> \n> So instead of doing\n> \n> \tgit-cat-file commit <id>\n> \n> (or whatever you do), just do\n> \n> \tgit-rev-list --parents --pretty=raw --max-count=1 <id>\n\nThat would be nice, if I could convert everthing to this output format.\n\nBut why does --pretty=raw mangle the text with spaces?\nWell the output of this  weird word combination may be \"pretty\" but definitely\nnot \"raw\". :)\n\nAnd I would prefer --pretty=raw with '\\0' termination instead of '\\n' so I can\nreplace the output from --header with --pretty=raw and can still use the same\nparsing routine.\n\nThanks,\nKay\n"},{"id":"8444","messageId":"Pine.LNX.4.58.0509121603490.3266@g5.osdl.org","threadId":"1783","inReplyTo":"20050912225032.GA8360@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-12T23:06:08Z","receivedAt":"2005-09-12T23:06:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 13 Sep 2005, Kay Sievers wrote:\n> \n> But why does --pretty=raw mangle the text with spaces?\n> Well the output of this  weird word combination may be \"pretty\" but definitely\n> not \"raw\". :)\n\ngit-rev-list always makes sure that the header is clearly separated. We \ncould have a \"really-raw\" format, of course, but..\n\n> And I would prefer --pretty=raw with '\\0' termination instead of '\\n' so I can\n> replace the output from --header with --pretty=raw and can still use the same\n> parsing routine.\n\nDang. That's one of the few programs that don't take -z.\n\nWe could add it, but then you'd have to wait for that to percolate out \nagain..\n\n\t\tLinus\n"},{"id":"8445","messageId":"Pine.LNX.4.58.0509121608130.3266@g5.osdl.org","threadId":"1783","inReplyTo":"20050912225032.GA8360@vrfy.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-12T23:09:58Z","receivedAt":"2005-09-12T23:09:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 13 Sep 2005, Kay Sievers wrote:\n> \n> And I would prefer --pretty=raw with '\\0' termination instead of '\\n' so I can\n> replace the output from --header with --pretty=raw and can still use the same\n> parsing routine.\n\nIt struck me that \"--header\" works fine with \"--parents\".\n\nSo if you're currently already using \"git-rev-list --header\" and parsing \nthat, just add \"--parents\" and off you go. That's basically the same as \n--pretty=raw + zero-termination.\n\n\t\tLinus\n"},{"id":"8448","messageId":"20050912235149.GA10513@vrfy.org","threadId":"1783","inReplyTo":"Pine.LNX.4.58.0509121608130.3266@g5.osdl.org","subject":"Re: hmm, can't we give the \"root\" a parent?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-12T23:51:49Z","receivedAt":"2005-09-12T23:51:49Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Mon, Sep 12, 2005 at 04:09:58PM -0700, Linus Torvalds wrote:\n> \n> \n> On Tue, 13 Sep 2005, Kay Sievers wrote:\n> > \n> > And I would prefer --pretty=raw with '\\0' termination instead of '\\n' so I can\n> > replace the output from --header with --pretty=raw and can still use the same\n> > parsing routine.\n> \n> It struck me that \"--header\" works fine with \"--parents\".\n> \n> So if you're currently already using \"git-rev-list --header\" and parsing \n> that, just add \"--parents\" and off you go. That's basically the same as \n> --pretty=raw + zero-termination.\n\nYeah, got the same idea. :) Have it already working. With the history tree\nplugged in after \"Linux 2.6.12-rc2\":\n   http://ehlo.org/~kay/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h=2d137c24e9f433e37ffd10b3d5f418157589a8d2\n\nGrafting worked pretty nice by just doing:\n  echo \"8d38eadb7a97f265f7b3a9e8a30df358c3a546c8 e7e173af42dbf37b1d946f9ee00219cb3b2bea6a\" > $LOCALROOT/linux/kernel/git/torvalds/linux-2.6.git/info/grafts\n  echo $LOCALROOT/linux/kernel/git/tglx/history.git/objects > $LOCALROOT/linux/kernel/git/torvalds/linux-2.6.git/objects/info/alternates\n\nThanks,\nKay\n"},{"id":"8682","messageId":"12c511ca0509160839391ea012@mail.gmail.com","threadId":"1783","inReplyTo":"20050912181101.GA22221@vrfy.org","subject":"gitweb search in multi-headed tree","fromName":"Tony Luck","fromEmail":"tony.luck@gmail.com","sentAt":"2005-09-16T15:39:20Z","receivedAt":"2005-09-16T15:39:20Z","isPatch":false,"sender":{"key":"tony.luck@gmail.com","avatar":null},"body":"Kay,\n\nMy tree on kernel.org (.../aegl/linux-2.6.git) has two branches in\nrefs/heads: release\nand test.  The HEAD symlink points to the release branch.\n\nIt seems that a search traverses from HEAD to root, so can only find\nthings in the\nrelease branch.  I tried clicking on the \"test\" branch link at the\nfoot of the top-level\npage before doing the search ... but it still seems to search from HEAD.\n\nAny syntax I'm missing for this search?\n\n-Tony\n"},{"id":"8743","messageId":"20050917012238.GA29720@vrfy.org","threadId":"1783","inReplyTo":"12c511ca0509160839391ea012@mail.gmail.com","subject":"Re: gitweb search in multi-headed tree","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-17T01:22:38Z","receivedAt":"2005-09-17T01:22:38Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Fri, Sep 16, 2005 at 08:39:20AM -0700, Tony Luck wrote:\n> Kay,\n> \n> My tree on kernel.org (.../aegl/linux-2.6.git) has two branches in\n> refs/heads: release\n> and test.  The HEAD symlink points to the release branch.\n> \n> It seems that a search traverses from HEAD to root, so can only find\n> things in the\n> release branch.  I tried clicking on the \"test\" branch link at the\n> foot of the top-level\n> page before doing the search ... but it still seems to search from HEAD.\n> \n> Any syntax I'm missing for this search?\n\nYou can only append \"&h=test\" to the search url now. I will change that\nwith the next version of gitweb to let the search follow the current $hash.\n\nThanks,\nKay\n"}]}