Linux BKCVS kernel history git import..

Linux BKCVS kernel history git import..

[Linus Torvalds]

Ok, I'm uploading my current git CVS import results to kernel.org right
now, which is my current best effort (meaning: I may try to improve on it
even if there aren't any more cvsps bugs/features I have to fix, and
obviously I'll re-create it if there _are_ cvsps or cvsimport bugs that
cause the import to have problems).

I've "verified" it in the sense that I've done a "git-whatchanged -p" at
various stages of the import, and it looked sane. I also compared doing a
tar-tree-export of the 2.6.12-rc2 release, which exists both in my current
git tree _and_ in the old bkcvs tree, and they compared identically apart
from the fact that the bkcvs tree has the BitKeeper/ directory and a
ChangeSet file.

It's also pretty aggressively packed - I used "--window=50 --depth=50"  
(rather than the default 10 for both) to make the archive smaller, so it's
going to be somewhat more CPU-intensive to use (due to the possibly longer
delta chains), but it got the pack-file down from 204MB to 166MB, which I
think is pretty damn good for three years of history or whatever it is.

Especially considering that a gzip -9'd tar-file of the 2.6.12-rc2 release
is 45MB all on its own, that archive is just 3.6 times a single tree.

Of course, this _is_ the cvs import, which means that it's basically just
a straight-line linearization of the real BK history, but it's a pretty
good linearization and so it's certainly useful.

If somebody adds some logic to "parse_commit()" to do the "fake parent"
thing, you can stitch the histories together and see the end result as one
big tree. Even without that, you can already do things like

	git diff v2.6.10..v2.6.12

(which crosses the BK->git transition) by just copying the 166MB pack-file 
over, along with the tags that come with the thing. I've not verified it, 
but if that doesn't work, then it's a git bug. It _should_ work.

BIG NOTE! This is definitely one archive you want to "rsync" instead of
closing with a git repack. The unpacked archive is somewhere in the 2.4GB
region, and since I actually used a higher compression ratio than the
default, you'll transfer a smaller pack that way anyway.

It will probably take a while to mirror out (in fact, as I write this, the
DSL upload just from my local machine out still has fifteen minutes to
go), but it should be visible out there soonish. Please holler if you find
any problems with the conversion, or if you just have suggestions for
improvments.

It actually took something like 16 hours to do the conversion on my
machine (most of it appears to have been due to CVS being slow, the git
parts were quick), so I won't re-convert for any trivial things.

I'm planning on doing the 2.4 tree too some day - either as a separate
branch in the same archive, or as a separate git archive, I haven't quite
decided yet. But I was more interested int he 2.6.x tree (for obvious
reasons), and before I do the 2.4.x one I'd like to give that tree some
time for people to check if the conversion was ok.

One thing that could be verified, for example (but that I have _not_
done), is to do a few random "git diff v2.6.x..v2.6.y" and comparing the
result with the standard diffs that are out there. Just to verify that the
archive looks ok. I assume there is some "diff-compare" out there that can
handle the fact that the files are diffed in a different order (and with
different flags) etc.

		Linus

Re: Linux BKCVS kernel history git import..

[Diego Calleja]

El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
Linus Torvalds <torvalds@osdl.org> escribió:

> I'm planning on doing the 2.4 tree too some day - either as a separate
> branch in the same archive, or as a separate git archive, I haven't quite

It'd be great  to have the same thing but for the 1.0 - 2.2 tree. Of course
there are no "changelogs" for that, but incremental patches are still
available, and it'd be very interesting (for "historical reasons") to see how
things were added/removed

Re: Linux BKCVS kernel history git import..

[A Large Angry SCM]

Diego Calleja wrote:
> El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
> Linus Torvalds <torvalds@osdl.org> escribió:
> 
>>I'm planning on doing the 2.4 tree too some day - either as a separate
>>branch in the same archive, or as a separate git archive, I haven't quite
> 
> It'd be great  to have the same thing but for the 1.0 - 2.2 tree. Of course
> there are no "changelogs" for that, but incremental patches are still
> available, and it'd be very interesting (for "historical reasons") to see how
> things were added/removed

Also a really good stress test for the various git-blame/git-annotate
implementations.

Re: Linux BKCVS kernel history git import..

[David Woodhouse]

On Tue, 2005-07-26 at 11:57 -0700, Linus Torvalds wrote:
> If somebody adds some logic to "parse_commit()" to do the "fake parent"
> thing, you can stitch the histories together and see the end result as one
> big tree. Even without that, you can already do things like
> 
>         git diff v2.6.10..v2.6.12

That's a bit of a hack which really doesn't belong in the git tools.
It's not particularly hard to reparent the tree for real -- I'd much
rather see a tool added to git which can _actually_ change the
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of
0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding
SHA1 changes up to the current HEAD.

Note that the latter commit ID I gave there was actually the 2.6.12-rc2
commit in Thomas' history import, not your own. Thomas has done a lot of
work on it, and it has the full names extracted from the shortlog
script, full timestamps, branch/merge history and consistent character
sets in the commit logs. I'd definitely suggest that you use that
instead of the import from bkcvs.

http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=summary

-- 
dwmw2

Re: Linux BKCVS kernel history git import..

[Linus Torvalds]

On Wed, 27 Jul 2005, David Woodhouse wrote:

> On Tue, 2005-07-26 at 11:57 -0700, Linus Torvalds wrote:
> > If somebody adds some logic to "parse_commit()" to do the "fake parent"
> > thing, you can stitch the histories together and see the end result as one
> > big tree. Even without that, you can already do things like
> > 
> >         git diff v2.6.10..v2.6.12
> 
> That's a bit of a hack which really doesn't belong in the git tools.

Actually, it's not a hack at all. It's very fundamentally how git works: 
you give it two trees that it knows about, and it will show the 
differences between them - regardless of whether they share any common 
ancestry or not.

> It's not particularly hard to reparent the tree for real -- I'd much
> rather see a tool added to git which can _actually_ change the
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of
> 0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding
> SHA1 changes up to the current HEAD.

I used to think I wanted to, but these days I really don't. One of the
reasons is that I expect to try to pretty up the old bkcvs conversion some
time: use the name translation from the old "shortlog" scripts etc, and
see if I can do some other improvements on the conversion (I think I'll
remove the BK files - "ChangeSet" etc).

And it's really much easier and more general to have a "graft" facility.  
It's something that git can do trivially (literally a hook in
"parse_commit" to add a special parent), and it's actually a generic
mechanism exactly for issues like this ("project had old history in some
other format").

Somebody already asked for having the import history for old historic 
patches - which we _do_ actually have as patches, but which obviously 
don't have any changelogs except for the version information. Most people 
may not want that, but the thing is, with a "graft" facility, the people 
who _do_ want that can easily see it all, and it is totally seamless.

So it's not even a one-time hack - it's a real feature that just in the 
kernel would have several cases we'd be able to use it for, and the same 
is likely true for almost any other project that wasn't started purely 
from git..

		Linus

Re: Linux BKCVS kernel history git import..

[David Woodhouse]

On Wed, 2005-07-27 at 08:29 -0700, Linus Torvalds wrote:
> I used to think I wanted to, but these days I really don't. One of the
> reasons is that I expect to try to pretty up the old bkcvs conversion some
> time: use the name translation from the old "shortlog" scripts etc, and
> see if I can do some other improvements on the conversion (I think I'll
> remove the BK files - "ChangeSet" etc).

Thomas has done all that; it's on kernel.org already.

> And it's really much easier and more general to have a "graft" facility.  
> It's something that git can do trivially (literally a hook in
> "parse_commit" to add a special parent), and it's actually a generic
> mechanism exactly for issues like this ("project had old history in some
> other format").

Hm, OK. That works and can also be used for the "fake _absence_ of
parent" thing -- if I'm space-constrained and want only the history back
to some relatively recent point like 2.6.0, I can do that by turning the
2.6.0 commit into an orphan instead of also using all the rest of the
history back to 2.4.0. 

-- 
dwmw2

Re: Linux BKCVS kernel history git import..

[Linus Torvalds]

On Wed, 27 Jul 2005, David Woodhouse wrote:
> 
> Hm, OK. That works and can also be used for the "fake _absence_ of
> parent" thing -- if I'm space-constrained and want only the history back
> to some relatively recent point like 2.6.0, I can do that by turning the
> 2.6.0 commit into an orphan instead of also using all the rest of the
> history back to 2.4.0. 

Yes. The grafting really should work pretty well for various things like
this, and at the same time I don't think it's ever going to be a huge 
problem: people may have a couple of graft-points (if you want to drop 
history, you may well have more than one point you need to "cauterize": 
you may not be able to just cut it off at 2.6.0, since there may be merges 
furhter back in history), but I don't think it's going to explode and 
become unwieldly.

I just don't see people having more than a few trees that they might want
to graft together, and while the "drop history" thing might cause more
issues, even that is bounded by the amount of development parallellism, so 
while it probably causes more graft-points than the "join trees" usage, it 
should still be just a small handful of points.

			Linus

[PATCH] Teach parse_commit_buffer about grafting.

[Junio C Hamano]

Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
which is a list of "fake commit parent records".  Each line of
this file is a commit ID, followed by parent commit IDs, all
40-byte hex SHA1 separated by a single SP in between.  The
records override the parent information we would normally read
from the commit objects, allowing both adding "fake" parents
(i.e. grafting), and pretending as if a commit is not a child of
some of its real parents (i.e. cauterizing).

Bugs are mine, but the credits for the idea and implementation
outline all go to Linus, who kept hinting how this thing should
work.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 cache.h     |    2 +
 commit.c    |  114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sha1_file.c |   13 ++++++-
 3 files changed, 127 insertions(+), 2 deletions(-)

0f16b172aa7f0757b2af50ec7be58dc0e23913a6
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -127,10 +127,12 @@ extern unsigned int active_nr, active_al
 #define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
 #define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
 #define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
+#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
 
 extern char *get_object_directory(void);
 extern char *get_refs_directory(void);
 extern char *get_index_file(void);
+extern char *get_graft_file(void);
 
 #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
 
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -91,11 +91,108 @@ static unsigned long parse_commit_date(c
 	return date;
 }
 
+static struct commit_graft {
+	unsigned char sha1[20];
+	int nr_parent;
+	unsigned char parent[0][20]; /* more */
+} **commit_graft;
+static int commit_graft_alloc, commit_graft_nr;
+
+static int commit_graft_pos(const unsigned char *sha1)
+{
+	int lo, hi;
+	lo = 0;
+	hi = commit_graft_nr;
+	while (lo < hi) {
+		int mi = (lo + hi) / 2;
+		struct commit_graft *graft = commit_graft[mi];
+		int cmp = memcmp(sha1, graft->sha1, 20);
+		if (!cmp)
+			return mi;
+		if (cmp < 0)
+			hi = mi;
+		else
+			lo = mi + 1;
+	}
+	return -lo - 1;
+}
+
+static void prepare_commit_graft(void)
+{
+	char *graft_file = get_graft_file();
+	FILE *fp = fopen(graft_file, "r");
+	char buf[1024];
+	if (!fp) {
+		commit_graft = (struct commit_graft **) "hack";
+		return;
+	}
+	while (fgets(buf, sizeof(buf), fp)) {
+		/* The format is just "Commit Parent1 Parent2 ...\n" */
+		int len = strlen(buf);
+		int i;
+		struct commit_graft *graft = NULL;
+
+		if (buf[len-1] == '\n')
+			buf[--len] = 0;
+		if (buf[0] == '#')
+			continue;
+		if ((len + 1) % 41) {
+		bad_graft_data:
+			error("bad graft data: %s", buf);
+			free(graft);
+			continue;
+		}
+		i = (len + 1) / 41 - 1;
+		graft = xmalloc(sizeof(*graft) + 20 * i);
+		graft->nr_parent = i;
+		if (get_sha1_hex(buf, graft->sha1))
+			goto bad_graft_data;
+		for (i = 40; i < len; i += 41) {
+			if (buf[i] != ' ')
+				goto bad_graft_data;
+			if (get_sha1_hex(buf + i + 1, graft->parent[i/41]))
+				goto bad_graft_data;
+		}
+		i = commit_graft_pos(graft->sha1);
+		if (0 <= i) {
+			error("duplicate graft data: %s", buf);
+			free(graft);
+			continue;
+		}
+		i = -i - 1;
+		if (commit_graft_alloc <= ++commit_graft_nr) {
+			commit_graft_alloc = alloc_nr(commit_graft_alloc);
+			commit_graft = xrealloc(commit_graft,
+						sizeof(*commit_graft) *
+						commit_graft_alloc);
+		}
+		if (i < commit_graft_nr)
+			memmove(commit_graft + i + 1,
+				commit_graft + i,
+				(commit_graft_nr - i - 1) *
+				sizeof(*commit_graft));
+		commit_graft[i] = graft;
+	}
+	fclose(fp);
+}
+
+static struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
+{
+	int pos;
+	if (!commit_graft)
+		prepare_commit_graft();
+	pos = commit_graft_pos(sha1);
+	if (pos < 0)
+		return NULL;
+	return commit_graft[pos];
+}
+
 int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
 {
 	char *bufptr = buffer;
 	unsigned char parent[20];
 	struct commit_list **pptr;
+	struct commit_graft *graft;
 
 	if (item->object.parsed)
 		return 0;
@@ -109,17 +206,32 @@ int parse_commit_buffer(struct commit *i
 		add_ref(&item->object, &item->tree->object);
 	bufptr += 46; /* "tree " + "hex sha1" + "\n" */
 	pptr = &item->parents;
+
+	graft = lookup_commit_graft(item->object.sha1);
 	while (!memcmp(bufptr, "parent ", 7)) {
 		struct commit *new_parent;
 
 		if (get_sha1_hex(bufptr + 7, parent) || bufptr[47] != '\n')
 			return error("bad parents in commit %s", sha1_to_hex(item->object.sha1));
+		bufptr += 48;
+		if (graft)
+			continue;
 		new_parent = lookup_commit(parent);
 		if (new_parent) {
 			pptr = &commit_list_insert(new_parent, pptr)->next;
 			add_ref(&item->object, &new_parent->object);
 		}
-		bufptr += 48;
+	}
+	if (graft) {
+		int i;
+		struct commit *new_parent;
+		for (i = 0; i < graft->nr_parent; i++) {
+			new_parent = lookup_commit(graft->parent[i]);
+			if (!new_parent)
+				continue;
+			pptr = &commit_list_insert(new_parent, pptr)->next;
+			add_ref(&item->object, &new_parent->object);
+		}
 	}
 	item->date = parse_commit_date(bufptr);
 	return 0;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -61,7 +61,8 @@ static int get_sha1_file(const char *pat
 	return get_sha1_hex(buffer, result);
 }
 
-static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir;
+static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
+	*git_graft_file;
 static void setup_git_env(void)
 {
 	git_dir = gitenv(GIT_DIR_ENVIRONMENT);
@@ -79,6 +80,9 @@ static void setup_git_env(void)
 		git_index_file = xmalloc(strlen(git_dir) + 7);
 		sprintf(git_index_file, "%s/index", git_dir);
 	}
+	git_graft_file = gitenv(GRAFT_ENVIRONMENT);
+	if (!git_graft_file)
+		git_graft_file = strdup(git_path("info/grafts"));
 }
 
 char *get_object_directory(void)
@@ -102,6 +106,13 @@ char *get_index_file(void)
 	return git_index_file;
 }
 
+char *get_graft_file(void)
+{
+	if (!git_graft_file)
+		setup_git_env();
+	return git_graft_file;
+}
+
 int safe_create_leading_directories(char *path)
 {
 	char *pos = path;

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> Introduce a new file $GIT_DIR/info/grafts

Nice work.

Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Whatever occurs from love is always beyond good and evil.
		-- Friedrich Nietzsche

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Johannes Schindelin]

Hi,

is it possible that you forgot to initialize commit_graft_nr to 0?

Ciao,
Dscho

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Wolfgang Denk]

In message <7vslxw4tb1.fsf_-_@assigned-by-dhcp.cox.net> you wrote:
> Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
> which is a list of "fake commit parent records".  Each line of
> this file is a commit ID, followed by parent commit IDs, all
> 40-byte hex SHA1 separated by a single SP in between.  The
> records override the parent information we would normally read
> from the commit objects, allowing both adding "fake" parents
> (i.e. grafting), and pretending as if a commit is not a child of
> some of its real parents (i.e. cauterizing).

How exactly is this used?

I gave up trying to have CVS  merges  autimatically  recognized  upon
import, and tried to follow Matthias Urlichs' advice to fake it using
the grafts file.

I have this situation:

Branch point (actually this is the inital import into CVS):

Commit:	0b666f81da14bf46cada222856762f7fd6641c26
Child:  9956b03b956994bb4e2cee4161f3626bcfd71924 (Das U-Boot: Universal Boot Loader)
Child:  7309612797ed5e6b3b20027e28bca970b4f6b8fd (Initial revision)


End of branch to merge (in CVS 1.1.1.1):

Commit:	d9af3c87df93e1a8126b1a52adf8db978e9a0d40
Parent: 0bb9c6d97b195bd0efcdda02f109e6d1519074a9 (Das U-Boot: Universal Boot Loader)
<no child>


This is the commit where I would like to show the  branch  merged  in
(before; this is the first real commit in CVS):

Commit:	24ee89b97a49826ea800b4a6c0d5c0769328e317
Parent: de180e6daa529dc78668c99bdf17a9cdd440782d (Initial revision)
Child:  699b13a6064e642280caffaa83c10b359a6c1114 (* Fix mdelay() on TRAB - this was still the debugging version with)


I tried with a grafts file like this:

24ee89b97a49826ea800b4a6c0d5c0769328e317 de180e6daa529dc78668c99bdf17a9cdd440782d d9af3c87df93e1a8126b1a52adf8db978e9a0d40


The display in gitk --all gets changed a bit (before the  branch  was
the  leftmost  line,  now  it's  the rightmost one), but it's still a
dangling head, and the selected  "merge  point"  (commit  24ee89)  is
still  displayed  with  just  one parent (de180e) - I would expect to
also see d9af3c listed as parent, and the branch merging in here?

Am I missing something?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
        "That we but teach bloody instructions,
        which, being taught, return to plague the inventor..."

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Junio C Hamano]

Wolfgang Denk <wd@denx.de> writes:

> The display in gitk --all gets changed a bit (before the  branch  was
> the  leftmost  line,  now  it's  the rightmost one), but it's still a
> dangling head, and the selected  "merge  point"  (commit  24ee89)  is
> still  displayed  with  just  one parent (de180e) - I would expect to
> also see d9af3c listed as parent, and the branch merging in here?
>
> Am I missing something?

The graft info is not used by anything other than those that use
parse_commit() to figure out the commit ancestry information.

The list of commits that appear in the top pane of the gitk is
generated by git-rev-list which knows how to do it, but the
parent and child links, and the lines between nodes are drawn by
gitk using the information it reads directly from the commit
objects.

My Tcl/Tk is really rusty, and I do not like this patch, but
here is my stab at teaching the code that reads commit objects
how to use grafts as well.

------------
[PATCH] Teach gitk to use grafts info

Finding commits to draw is done by git-rev-list which knows how
to do the grafts, but the lines between commits and the
parent / child links needs to be drawn by reading from the
commit objects.  Teach that part of the code how to grok grafts
info so that "fake" ancestry is shown sensibly in gitk.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 gitk |   36 +++++++++++++++++++++++++++++++++++-
 1 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -155,7 +155,7 @@ proc readcommit {id} {
 }
 
 proc parsecommit {id contents listed} {
-    global commitinfo children nchildren parents nparents cdate ncleft
+    global commitinfo children nchildren parents nparents cdate ncleft grafts
 
     set inhdr 1
     set comment {}
@@ -171,6 +171,23 @@ proc parsecommit {id contents listed} {
     }
     set parents($id) {}
     set nparents($id) 0
+    set has_graft [array get grafts $id]
+    if {"" != $has_graft} {
+	set parents($id) $grafts($id)
+	set nparents($id) [llength $parents($id)]
+	foreach p $parents($id) {
+	    if {![info exists nchildren($p)]} {
+		set children($p) {}
+		set nchildren($p) 0
+		set ncleft($p) 0
+	    }
+	    if {$listed && [lsearch -exact $children($p) $id] < 0} {
+		lappend children($p) $id
+		incr nchildren($p)
+		incr ncleft($p)
+	    }
+	}
+    }
     foreach line [split $contents "\n"] {
 	if {$inhdr} {
 	    if {$line == {}} {
@@ -178,6 +195,9 @@ proc parsecommit {id contents listed} {
 	    } else {
 		set tag [lindex $line 0]
 		if {$tag == "parent"} {
+		    if {"" != $has_graft} {
+			continue
+		    }
 		    set p [lindex $line 1]
 		    if {![info exists nchildren($p)]} {
 			set children($p) {}
@@ -3194,6 +3214,20 @@ foreach arg $argv {
 
 set history {}
 set historyindex 0
+set grafts('') nothing
+array unset grafts ''
+if {![catch { set graft [exec cat [gitdir]/info/grafts] }]} {
+    global grafts
+    foreach line [split $graft "\n"] {
+	set commit [lindex $line 0]
+	set llen [llength $line]
+	set pp {}
+	for {set i 1} {$i < $llen} {incr i} {
+	    lappend pp [lindex $line $i]
+	}
+	set grafts($commit) $pp
+    }
+}
 
 set stopped 0
 set redisplaying 0

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Paul Mackerras]

Junio C Hamano writes:

> My Tcl/Tk is really rusty, and I do not like this patch, but
> here is my stab at teaching the code that reads commit objects
> how to use grafts as well.

I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now.  I also committed the changes to send lines into
hyperspace.

Regards,
Paul.

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Linus Torvalds]

On Thu, 18 Aug 2005, Paul Mackerras wrote:
> 
> I added support for grafts to gitk just yesterday, and it should be on
> kernel.org by now.  I also committed the changes to send lines into
> hyperspace.

Paul, I hate to tell you about yet another flag to git-rev-list, but did 
you realize that in addition to all the other magic flags, there's a flag 
called "--parents"?

Right now you use "git-rev-list --header --topo-order", which gives you 
both the commit ID's and the header. Add a "--parents" there, and you'll 
notice that the first line of each NUL-terminated record changes from just 
the commit ID to the "commit ID + parent list".

That way gitk wouldn't need to actually know about grafts, because it 
would just pick it up from the git-rev-list output which gets it from the 
regular commit parsing code.

Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
need to look at any other internal git information, you're probably doing
something wrong, or you've missed yet another flag ;)

		Linus

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Paul Mackerras]

Linus Torvalds writes:

> Paul, I hate to tell you about yet another flag to git-rev-list, but did 
> you realize that in addition to all the other magic flags, there's a flag 
> called "--parents"?

Cool.  I didn't realize that.  The current version uses it now.

> Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
> need to look at any other internal git information, you're probably doing
> something wrong, or you've missed yet another flag ;)

I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
flag have I missed? :)  Junio wants me to look at everything under
[gitdir]/refs, in fact.  Or are the refs not considered internal git
information?

Paul.

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Johannes Schindelin]

Hi,

On Fri, 19 Aug 2005, Paul Mackerras wrote:

> Linus Torvalds writes:
> 
> > Paul, I hate to tell you about yet another flag [...]

But why? You're doing such a fine job telling people about flags :-)

> > Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
> > need to look at any other internal git information, you're probably doing
> > something wrong, or you've missed yet another flag ;)
> 
> I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
> flag have I missed? :)  Junio wants me to look at everything under
> [gitdir]/refs, in fact.  Or are the refs not considered internal git
> information?

Time for git-ref-list?

Joking. But there may be a use for a "--refs" flag to git-rev-list, which 
just lists all the refs' names together with their object name (SHA1).

Ciao,
Dscho

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Linus Torvalds]

On Fri, 19 Aug 2005, Paul Mackerras wrote:
> 
> > Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
> > need to look at any other internal git information, you're probably doing
> > something wrong, or you've missed yet another flag ;)
> 
> I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
> flag have I missed? :)  Junio wants me to look at everything under
> [gitdir]/refs, in fact.  Or are the refs not considered internal git
> information?

Ahh, ok, fair enough. git-rev-list won't give you that. 

And yes, the general rule is that anything under .git/refs/ is potentially 
a reference. If it's under "heads/" or "tags/" it's a branch/tag, and then 
the prefix "heads/" or "tags/" shouldn't be part of the name - you already 
show the difference with colors. Anything else is unusual, but bisection 
puts refs in the ".git/refs/bisect" directory for example, and if gitk 
were to show those, it should probably show them in yet another color, and 
_with_ the "bisect/" prefix..

		Linus