Jakub Narebski <jnareb@xxxxxxxxx> writes: > 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. > 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"? > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html