Andreas Ericsson wrote:
...
The only problem I'm seeing atm is that the supermodule somehow has to
mark whatever commits it's using from the submodule inside the submodule
repo so that they effectively become un-prunable, otherwise the
supermodule may some day find itself with a history that it can't restore.
That has nothing to do with submodules. What you state here is the
problem of alternate repositories.
There are two solutions:
1. Do not use alternates.
2. Do not prune a repository that is used as an alternate repository by
other repositories.
For the submodule discussion that would mean:
1. Only fetch and work on branches of submodules you are interested in.
It does not matter that the origin repository contains (probably orders
of magnitude) more data. You will never touch that.
2. You can never prune the main (the supermodule's) repository, at least
not with what git provides today.
That is why the sanest approach to subprojects is to put commits into
tree objects, define a way to name these commits and make git understand
these new commit names. Done. Works.
Regards
Stephan
-
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