hmm, can't we give the "root" a parent?

hmm, can't we give the "root" a parent?

[Kay Sievers]

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

Re: hmm, can't we give the "root" a parent?

[Linus Torvalds]

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?

[Kay Sievers]

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

Re: hmm, can't we give the "root" a parent?

[Linus Torvalds]

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?

[Kay Sievers]

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

Re: hmm, can't we give the "root" a parent?

[Linus Torvalds]

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?

[Kay Sievers]

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

Re: hmm, can't we give the "root" a parent?

[Linus Torvalds]

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

Re: hmm, can't we give the "root" a parent?

[Linus Torvalds]

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?

[Kay Sievers]

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

Re: hmm, can't we give the "root" a parent?

[A Large Angry SCM]

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

[Tony Luck]

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

[Kay Sievers]

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