# hmm, can't we give the "root" a parent? 13 messages from 2005-09-12 to 2005-09-17. Participants: Kay Sievers, A Large Angry SCM, Linus Torvalds, Tony Luck. Thread: https://gitlist.dev/t/1783 ## Kay Sievers, 2005-09-12 18:11 Subject: hmm, can't we give the "root" a parent? Message-ID: <20050912181101.GA22221@vrfy.org> URL: https://gitlist.dev/e/20050912181101.GA22221%40vrfy.org ``` Can't we teach the git tools that a "root commit" (one without a any parent) is not visible as a "root", if let's say: .git/parents/ -> does connect a "fake" parent to the "root"? This way we could add any older Linux history to the current tree. Combined with "alternates" it could live in a complete different repository too. Thanks, Kay ``` ## Linus Torvalds, 2005-09-12 18:26 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121123280.3242%40g5.osdl.org In-Reply-To: <20050912181101.GA22221@vrfy.org> ``` On Mon, 12 Sep 2005, Kay Sievers wrote: > > Can't we teach the git tools that a "root commit" (one without a any > parent) is not visible as a "root", if let's say: > .git/parents/ -> > > does connect a "fake" parent to the "root"? This way we could add any > older Linux history to the current tree. Combined with "alternates" it > could live in a complete different repository too. Ehh.. That's exactly what "grafting" is about. So just do echo " " >> .git/info/grafts and it should all work. Of course, anything that parses the commits by hand won't see it, but all the regular tools hopefully do. Linus ``` ## A Large Angry SCM, 2005-09-12 18:27 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: <4325C89F.1030406@gmail.com> URL: https://gitlist.dev/e/4325C89F.1030406%40gmail.com In-Reply-To: <20050912181101.GA22221@vrfy.org> ``` Kay Sievers wrote: > Can't we teach the git tools that a "root commit" (one without a any > parent) is not visible as a "root", if let's say: > .git/parents/ -> > > does connect a "fake" parent to the "root"? This way we could add any > older Linux history to the current tree. Combined with "alternates" it > could live in a complete different repository too. Already done. Search the following for "info/grafts". http://www.kernel.org/pub/software/scm/git/docs/repository-layout.html ``` ## Kay Sievers, 2005-09-12 19:59 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: <20050912195947.GA28502@vrfy.org> URL: https://gitlist.dev/e/20050912195947.GA28502%40vrfy.org In-Reply-To: ``` On Mon, Sep 12, 2005 at 11:26:24AM -0700, Linus Torvalds wrote: > On Mon, 12 Sep 2005, Kay Sievers wrote: > > > > Can't we teach the git tools that a "root commit" (one without a any > > parent) is not visible as a "root", if let's say: > > .git/parents/ -> > > > > does connect a "fake" parent to the "root"? This way we could add any > > older Linux history to the current tree. Combined with "alternates" it > > could live in a complete different repository too. > > Ehh.. That's exactly what "grafting" is about. > > So just do > > echo " " >> .git/info/grafts > > and it should all work. > > Of course, anything that parses the commits by hand won't see it, but all > the regular tools hopefully do. Yup, tried it and works nicely with the history.git tree on kernel.org connected to your tree, replacing the initial commit. And good to know about that, need to fix the "parent" link in gitweb to respect grafts. Thanks, Kay ``` ## Linus Torvalds, 2005-09-12 20:21 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121316030.3266%40g5.osdl.org In-Reply-To: <20050912195947.GA28502@vrfy.org> ``` On Mon, 12 Sep 2005, Kay Sievers wrote: > > And good to know about that, need to fix the "parent" link in gitweb to > respect grafts. Note that the simplest way to do this is to try to use "git-rev-list" as much as possible. The "--parents" flag makes the output have the parents (automatically _including_ any grafts) on the line that contains the commit ID. That's especially true of any tools that use git-rev-list anyway for other reasons. Eg "gitk" could parse the parent stuff this way, and didn't need to know about the info/grafts file at all. I suspect the same should be true of gitweb. (So instead of trying to parse the parent info from the header of the commit, just do "git-rev-list --pretty --parents" and parse that). Linus ``` ## Kay Sievers, 2005-09-12 21:00 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: <20050912210006.GA32211@vrfy.org> URL: https://gitlist.dev/e/20050912210006.GA32211%40vrfy.org In-Reply-To: ``` On Mon, Sep 12, 2005 at 01:21:13PM -0700, Linus Torvalds wrote: > On Mon, 12 Sep 2005, Kay Sievers wrote: > > > > And good to know about that, need to fix the "parent" link in gitweb to > > respect grafts. > > Note that the simplest way to do this is to try to use "git-rev-list" as > much as possible. The "--parents" flag makes the output have the parents > (automatically _including_ any grafts) on the line that contains the > commit ID. > > That's especially true of any tools that use git-rev-list anyway for other > reasons. Eg "gitk" could parse the parent stuff this way, and didn't need > to know about the info/grafts file at all. I suspect the same should be > true of gitweb. Everthing that walk from one commit to another, uses git-rev-list, sure. But in the commit view, and the commitdiff the "parent" link and the parent that is passed to diff is read from the commit itself. > (So instead of trying to parse the parent info from the header of the > commit, just do "git-rev-list --pretty --parents" and parse that). I need only one parent: git-rev-list --parents --max-count=1 Hmm, it's one more exec, but I don't need to look at the grafts file or whatever will make it into git the next time I will look at it. :) Thanks, Kay ``` ## Linus Torvalds, 2005-09-12 21:42 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121438150.3266%40g5.osdl.org In-Reply-To: <20050912210006.GA32211@vrfy.org> ``` On Mon, 12 Sep 2005, Kay Sievers wrote: > > Everthing that walk from one commit to another, uses git-rev-list, sure. > But in the commit view, and the commitdiff the "parent" link and the parent > that is passed to diff is read from the commit itself. > > > (So instead of trying to parse the parent info from the header of the > > commit, just do "git-rev-list --pretty --parents" and parse that). > > I need only one parent: > git-rev-list --parents --max-count=1 Who don't you use that to show the comments too? So instead of doing git-cat-file commit (or whatever you do), just do git-rev-list --parents --pretty=raw --max-count=1 That way you don't get any extra fork/exec overhead - you get everything with one program. Linus ``` ## Kay Sievers, 2005-09-12 22:50 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: <20050912225032.GA8360@vrfy.org> URL: https://gitlist.dev/e/20050912225032.GA8360%40vrfy.org In-Reply-To: ``` On Mon, Sep 12, 2005 at 02:42:16PM -0700, Linus Torvalds wrote: > > > On Mon, 12 Sep 2005, Kay Sievers wrote: > > > > Everthing that walk from one commit to another, uses git-rev-list, sure. > > But in the commit view, and the commitdiff the "parent" link and the parent > > that is passed to diff is read from the commit itself. > > > > > (So instead of trying to parse the parent info from the header of the > > > commit, just do "git-rev-list --pretty --parents" and parse that). > > > > I need only one parent: > > git-rev-list --parents --max-count=1 > > Who don't you use that to show the comments too? > > So instead of doing > > git-cat-file commit > > (or whatever you do), just do > > git-rev-list --parents --pretty=raw --max-count=1 That would be nice, if I could convert everthing to this output format. But why does --pretty=raw mangle the text with spaces? Well the output of this weird word combination may be "pretty" but definitely not "raw". :) And I would prefer --pretty=raw with '\0' termination instead of '\n' so I can replace the output from --header with --pretty=raw and can still use the same parsing routine. Thanks, Kay ``` ## Linus Torvalds, 2005-09-12 23:06 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121603490.3266%40g5.osdl.org In-Reply-To: <20050912225032.GA8360@vrfy.org> ``` On Tue, 13 Sep 2005, Kay Sievers wrote: > > But why does --pretty=raw mangle the text with spaces? > Well the output of this weird word combination may be "pretty" but definitely > not "raw". :) git-rev-list always makes sure that the header is clearly separated. We could have a "really-raw" format, of course, but.. > And I would prefer --pretty=raw with '\0' termination instead of '\n' so I can > replace the output from --header with --pretty=raw and can still use the same > parsing routine. Dang. That's one of the few programs that don't take -z. We could add it, but then you'd have to wait for that to percolate out again.. Linus ``` ## Linus Torvalds, 2005-09-12 23:09 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121608130.3266%40g5.osdl.org In-Reply-To: <20050912225032.GA8360@vrfy.org> ``` On Tue, 13 Sep 2005, Kay Sievers wrote: > > And I would prefer --pretty=raw with '\0' termination instead of '\n' so I can > replace the output from --header with --pretty=raw and can still use the same > parsing routine. It struck me that "--header" works fine with "--parents". So if you're currently already using "git-rev-list --header" and parsing that, just add "--parents" and off you go. That's basically the same as --pretty=raw + zero-termination. Linus ``` ## Kay Sievers, 2005-09-12 23:51 Subject: Re: hmm, can't we give the "root" a parent? Message-ID: <20050912235149.GA10513@vrfy.org> URL: https://gitlist.dev/e/20050912235149.GA10513%40vrfy.org In-Reply-To: ``` On Mon, Sep 12, 2005 at 04:09:58PM -0700, Linus Torvalds wrote: > > > On Tue, 13 Sep 2005, Kay Sievers wrote: > > > > And I would prefer --pretty=raw with '\0' termination instead of '\n' so I can > > replace the output from --header with --pretty=raw and can still use the same > > parsing routine. > > It struck me that "--header" works fine with "--parents". > > So if you're currently already using "git-rev-list --header" and parsing > that, just add "--parents" and off you go. That's basically the same as > --pretty=raw + zero-termination. Yeah, got the same idea. :) Have it already working. With the history tree plugged in after "Linux 2.6.12-rc2": http://ehlo.org/~kay/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h=2d137c24e9f433e37ffd10b3d5f418157589a8d2 Grafting worked pretty nice by just doing: echo "8d38eadb7a97f265f7b3a9e8a30df358c3a546c8 e7e173af42dbf37b1d946f9ee00219cb3b2bea6a" > $LOCALROOT/linux/kernel/git/torvalds/linux-2.6.git/info/grafts echo $LOCALROOT/linux/kernel/git/tglx/history.git/objects > $LOCALROOT/linux/kernel/git/torvalds/linux-2.6.git/objects/info/alternates Thanks, Kay ``` ## Tony Luck, 2005-09-16 15:39 Subject: gitweb search in multi-headed tree Message-ID: <12c511ca0509160839391ea012@mail.gmail.com> URL: https://gitlist.dev/e/12c511ca0509160839391ea012%40mail.gmail.com In-Reply-To: <20050912181101.GA22221@vrfy.org> ``` Kay, My tree on kernel.org (.../aegl/linux-2.6.git) has two branches in refs/heads: release and test. The HEAD symlink points to the release branch. It seems that a search traverses from HEAD to root, so can only find things in the release branch. I tried clicking on the "test" branch link at the foot of the top-level page before doing the search ... but it still seems to search from HEAD. Any syntax I'm missing for this search? -Tony ``` ## Kay Sievers, 2005-09-17 01:22 Subject: Re: gitweb search in multi-headed tree Message-ID: <20050917012238.GA29720@vrfy.org> URL: https://gitlist.dev/e/20050917012238.GA29720%40vrfy.org In-Reply-To: <12c511ca0509160839391ea012@mail.gmail.com> ``` On Fri, Sep 16, 2005 at 08:39:20AM -0700, Tony Luck wrote: > Kay, > > My tree on kernel.org (.../aegl/linux-2.6.git) has two branches in > refs/heads: release > and test. The HEAD symlink points to the release branch. > > It seems that a search traverses from HEAD to root, so can only find > things in the > release branch. I tried clicking on the "test" branch link at the > foot of the top-level > page before doing the search ... but it still seems to search from HEAD. > > Any syntax I'm missing for this search? You can only append "&h=test" to the search url now. I will change that with the next version of gitweb to let the search follow the current $hash. Thanks, Kay ```