threads / discuss / 1783
Subject: hmm, can't we give the "root" a parent?
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/<root-commit-id> -> <fake-parent-id>
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 TorvaldsRe: hmm, can't we give the "root" a parent?
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/<root-commit-id> -> <fake-parent-id> > > 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 "<root-id> <grafted-parent-id>" >> .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
Re: hmm, can't we give the "root" a parent?
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/<root-commit-id> -> <fake-parent-id> > > > > 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 "<root-id> <grafted-parent-id>" >> .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 TorvaldsRe: hmm, can't we give the "root" a parent?
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
Re: hmm, can't we give the "root" a parent?
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 <id>
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 TorvaldsRe: hmm, can't we give the "root" a parent?
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 <id>
Who don't you use that to show the comments too?
So instead of doing
git-cat-file commit <id>
(or whatever you do), just do
git-rev-list --parents --pretty=raw --max-count=1 <id>
That way you don't get any extra fork/exec overhead - you get everything with one program.
Linus
Re: hmm, can't we give the "root" a parent?
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 <id> > > Who don't you use that to show the comments too? > > So instead of doing > > git-cat-file commit <id> > > (or whatever you do), just do > > git-rev-list --parents --pretty=raw --max-count=1 <id>
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 TorvaldsRe: hmm, can't we give the "root" a parent?
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 TorvaldsRe: hmm, can't we give the "root" a parent?
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
Re: hmm, can't we give the "root" a parent?
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
A Large Angry SCMRe: hmm, can't we give the "root" a parent?
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/<root-commit-id> -> <fake-parent-id> > > 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
gitweb search in multi-headed tree
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
Re: gitweb search in multi-headed tree
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