On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote: > So I'd _almost_ suggest just starting from a clean slate after all. > Keeping the old history around, of course, but not necessarily putting it > into git now. It would just force everybody who is getting used to git in > the first place to work with a 3GB archive from day one, rather than > getting into it a bit more gradually. > > What do people think? I'm not so much worried about the data itself: the > git architecture is _so_ damn simple that now that the size estimate has > been confirmed, that I don't think it would be a problem per se to put > 3.2GB into the archive. But it will bog down "rsync" horribly, so it will > actually hurt synchronization untill somebody writes the rev-tree-like > stuff to communicate changes more efficiently..
Note that any given copy of a tree doesn't _need_ to keep all the history back the beginning of time. It's OK if the oldest commit object in your tree actually refers back to a parent which doesn't exist locally. I can well imagine that some people will want to keep their trees pruned to keep only a few weeks of history, while other copies of the tree will keep everything. However, if we _don't_ base our current work on an existing import of the kernel, then we don't retain that option. We can't just change the 'parent' field of your 2.6.12-rc2 import, without changing the sha1 hash of _everything_ that happens thereafter. So I'd say we should take Thomas' import, and base new work on that -- but then possibly leave out the older objects from the 'working' repository which everyone is rsyncing from; just make them available in a 'linux-history.git' object database elsewhere. -- dwmw2 - 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
