On Fri, 15 Apr 2005, Barry Silverman wrote:
>
> The issue I am trying to come to grips with in the current design, is
> that the git repository of a number of interrelated projects will soon
> become the logical OR of all blobs, commits, and trees in ALL the
> projects.
Nope. I'm actually against the notion of sharing object directories
between projects. The git model _allows_ it, and I think it can be a valid
approach, but it's absolutely not an approach that I would personally
suggest be used for the kernel.
In other words, the default git behaviour - and the one I personally am a
proponent of - is to have one object directory per work tree, and really
consider all such trees independent. Then you can merge between trees if
you want to, and bring in objects that way, but normally you would _not_
have tons of objects from other trees, and _especially_ not from other
unrelated projects.
The reason git supports shared object archives is that (a) it falls out
trivially as part of the design, so not allowing it is silly and (b) it is
part of a merge, where you _do_ want to get the objects of the trees you
merge, and in particular you need to generate a seperate tree that has all
those objects without having to copy them.
(Before you do the merge, you need to bring the new objects into your
repository of course, but that I consider to be a separate issue, not
part of the actual technical merge process).
So normally, you'd probably have a totally pruned tree, with only the
objects you need (and you might even consider the "commit parent links"
less than necessary, especially if you're just a regular user and not a
developer who wants to merge).
But the ability to have extra objects is wonderful. It makes going
backwards in time basically free (while the equivalent "bk undo" in the BK
world is a very expensive operation), and it makes it easy to
incrementally keep up-to-date with trees that you know you're _eventually_
going to merge with. But it's not an excuse to put just any random crap in
that object directory..
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
