RE: Merge with git-pasky II.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 16, 2005, 00:32 UTC
Message-ID: <Pine.LNX.4.58.0504151723530.7211@ppc970.osdl.org>
In-Reply-To: <000701c5420e$e89177b0$6400a8c0@gandalf>

On Fri, 15 Apr 2005, Barry Silverman wrote:

Show 5 quoted lines

>
> 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