Jakub Narebski <jnareb@gmail.com> writes:

quoted text
> What might help here is splitting repository into current (e.g. from
> OOo 2.0) and historical part, and / or using shallow clone.

Yes, depending on where you cut off and how reasonable the
project history is.

quoted text
> Implementing 
> partial checkouts, i.e. checking out only part of working area (and 
> using 'theirs' strategy for merging not-checked-out part for merges) 
> would help.

Partial checkouts, perhaps, "theirs", NO.

Consider that you are working on the tip with partial checkout.
Somebody has a bugfix that is applicable to all of ancient, old,
maintenance and current codebase.  Naturally you would want the
bugfix to be applied to ancient, merge it to old, and then
maintenance and then current (the last one is what you are
working on).

What happens if you actually pull ancient when you are partially
checked out and use "theirs"?

quoted text
> Splitting repository into submodules, and submodule
> support -- it depends on organization of OOo sources, would certainly 
> help for third party stuff repository.

This is probably the most sane way.

-
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