Re: Linux BKCVS kernel history git import..

[Linus Torvalds <torvalds@osdl.org>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/