Andreas Ericsson wrote: > Uwe Kleine-Koenig wrote: > >> 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. >>> >> One could circumvent that by creating a separate repo for the submodule >> at checkout time and pull the needed objects in the supermodule's odb >> when commiting the supermodule. This way prune in the submodule cannot >> do any harm, because in it's odb are no objects that are important for >> the supermodule. > > Yes, but then you'd lose history connectivity (I'm assuming you'd only > pull in the tree and blob objects from the submodule, and prefix the > tree-entrys with whatever directory you're storing the submodul in). I thought that Uwe meant pulling (getting) _all_ the needed objects from submodule object repository into supermodule object repository: commits, trees and blobs, full history. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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