On Tue, May 22, 2007 at 09:37:06PM +0200, Jan Hudec wrote: > > We don't have to move the entire subproject.git into the superproject, > > but we need to have all _referenced_ objects in the .git dir of the > > superproject. > > > > There are several possibilities to do so: > > > > * move the entire .git dir > > * move .git/objects > > * explicitly copy all referenced objects > > I believe we really need entire .git dir. When the superporject checks out > revision which does not reference that subproject, we still need to preserve > not only the objects of subproject, but also the refs and config. but all the other refs do not belong to the superproject. For those who are working on the subproject there are of course a lot of refs which they have to work with, but that can be dealt with outside of the superproject scope. The subproject is still a normal Git repository, after all. That is, you can have remote entries, branches and what not. But all that is not interesting in the superproject scope. So I thing moving the entire subproject.git into the superproject.git is too much. The superproject is only interested in the objects and in one ref -- the one stored inside its tree. > > I have some experimental code to configure a per-subproject directory > > in the superproject/.git as alternate object store for the submodule > > to make the last two solutions possible. Perhaps I should dig it out again > > and adapt it to current git. > > > > If there is a 1:1 relationship between subproject and object store then > > even efficient fsck and repack/prune are possible for the submodule without > > loosing objects. > > But such a 1:1 relationship is bad when you move subprojects to another > > location (or include the same subproject several times in different > > locations of the tree). > > Perhaps the user should be able to choose which one he wants. > > That's why there should be the extra level of indirection using .gitmodules. > It should map the directory name to the object store name, so you can > relocate the subproject. > > Including the same project several times is indeed interesting. Maybe the > subprojects should be "light checkouts" (I believe something like this was > already discussed on the list sometime). Those would be .git dirs, that would > only have HEAD and pointer to another .git dir with everything else. Well, even if they might share a lot of objects they might be included for completely different reasons and so might need to work with different communities (remote entries, branches, etc.). So sharing objects makes sense, sharing the rest of .git is not neccessary. > > I think it will be _very_ common to store super and subprojects in > > related locations. First to be independent from third-party servers > > while working on the superproject. > > Second (and I think more important) because many times there will > > be superproject related adaptations in the subproject. Yes they > > are independent, and exactly for that reason the subproject upstream > > maintainers may not take every change which is needed to satisfy the > > superproject. We _now_ see that in all Linux distributions already. > > So when you use superprojects to integrate several independent projects, > > then the superproject maintainer/administrator should really keep a > > clone of all subprojects handy on his site. > > Yes, repositories with distribution-specific patches will add a large class > of cases requiring multiple sources support. You don't really need multiple sources for it. The subproject contains both upstream and local changes, but I think it makes sense to keep the entire object store local (the same way to keep all the entire history local even if you only want to add to it in a normal repository). Those people who work on the subproject and communicate with its upstream developers of course need remote entries and have to synchronize the subproject with upstream. But that is not related to the superproject at all. So yes, you have different sources but you don't need extra support in the subproject implementation for it. -- Martin Waitz
Attachment:
signature.asc
Description: Digital signature
