On Wed, May 02, 2007 at 04:24:24PM CEST, Jan Holesovsky wrote:
quoted text
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html