On Tue, 10 Apr 2007, Alex Riesen wrote: > > It is already "merged somewhere": as soon as the patches left landed > on vger, it is not possible to loose (and even destroy) them. > The feature is just too much sought after. Well, unless it hits something like Junios 'pu' (or 'next') branch, or somebody (like you?) ends up maintaining a repo with this, it's just unnecessarily hard to have lots of people working together on it.. I'm obviously interested in working on it, but at the same time, I don't expect to be a primary *user* of it, so I'm hoping others will come in and start looking at it. It looks promising that you're getting involved, but I suspect you may be a bit too optimistic when you say "just too much sought after". We've been *talking* about subprojects for a long long time, and we've had other patches fail. So... > > For example, with just two smallish updates: > > - teach "git upload-pack" not to try to follow gitlinks > > - teach "git read-tree" to check out a git-link as just an empty > > subdirectory > > which also should fix switching between the branches with subprojects. Yes. It would require either git-read-tree or the git-checkout script around it knowing to then also check out the subproject branches. It's actually not *entirely* obvious what you should do when you switch branches (or even just do a "git reset --hard") in the superproject. The branches in the subprojects are likely to be totally different from the superproject, so as far as I can see, you end up having two choices when you reset a subproject: - either basically create a "disconnected HEAD" in the subproject(s) when you switch them around as a consequence of resetting/switching the branch in the superproject. - or you'd stay on the same branch in the subproject, and just reset that branch.. - or you describe the branch name in the ".gitmodules" file in the superproject, and use whatever branch in the submodule that is described in the supermodule that you reset/check-out. - or possibly other policies. So there is bound to be various "policy" issues like this worth sorting out. I don't think they matter that deeply. I would _personally_ tend to like the notion of using ".gitmodules" in the supermodule to describe things like this, exactly because it's a policy decision - not something that git itself should really decide about, but that the supermodule maintainers can just decide to agree on. But I haven't really even thought about all the things I'd want to have in the .gitmodules. We'd obviously need to list the default URL's for the submodules some way etc, but I haven't really sat down and thought about what all the higher-level porcelain really would need to know. I suspect that somebody who has used and set up CVS "modules" setups should be thinking about that. I've been a "stupid user" for CVS modules setups, but I've never actually needed to really know how they *work*. Linus - 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