hoi :) On Sat, Dec 02, 2006 at 10:04:20AM +0000, Andy Parkins wrote: > On Friday 2006, December 01 22:08, Martin Waitz wrote: > > > > echo $SUBMODULE_HASH > > > > submodule/.git/refs/supermodules/commit$SUPERMODULE_HASH > > > > I guess you are aware that you have to scan _all_ trees inside _all_ > > supermodule commits for possible references. > > No you don't; you do it as part of the appropriate normal operations. > > * supermodule commit - scan the current tree for "link" objects in the > tree. If you find one write the reference in the submodule. > * adding a new submodule - if this is a new submodule there can't be any > references in the supermodule already. > * cloning a supermodule, every new commit that gets written in the > supermodule gets checked from "link" objects. * removing a branch from the supermodule. OK, this is an infrequent operation and it can be handled by redoing everything. I just don't like to duplicate information which is already available easily. We'd need much to many special cases, just to correctly support reachablility analysis. KISS. > > So what do you do with deleted submodules? > > You wouldn't want them to still sit around in your working directory, > > but you still have to preserve them. > > Now that is a tricky one. Mind you, I think that problem exists for any > implementation. I haven't got a good answer for that. If you just keep it in a shared object repository you don't have any problems. Please note that it is not required to keep it in one physical location. You can still use alternates/whatever to store some objects in another repository, but you need to be able to access all objects from the supermodule. -- Martin Waitz
Attachment:
signature.asc
Description: Digital signature