On Wed, May 02, 2007 at 04:24:24PM CEST, Jan Holesovsky wrote: > > What might help here is splitting repository into current (e.g. from > > OOo 2.0) and historical part, > > No, I don't want this ;-) Are you sure? Using the graft mechanism, Git can make this very easy and almost transparent for the user - when he clones he gets no history but he can use say some simple vendor-provided script to download the historical packfile and graft it to the 'current' tree. After that, the graft acts completely transparently and it 'seems' like the history goes on continuously from OOo prehistory up to the latest commit. Besides, in case you discover a year later that the conversion was broken in some places etc., you can just fix this, re-run the conversion and simply regraft your history to point at the 'new' historical commit, without affecting your current development and commit ids at all. For this reason alone, I'd seriously consider grafting history separately when migrating any non-trivial project from other SCM to Git. Then again, due to the sheer tree sizes etc., I'm not sure how much would throwing the history away actually reduce the packfile size. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html