On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik <rvs@xxxxxxx> wrote: > Agreed. But I guess I'd be less confused if "git submodule" didn't muck > with .git/config at all. Or are there any other consumers of the > information > that it puts there (except itself)? That I don't know. If there aren't any others, then I agree, I'm not sure what the whole .git/config messing is about. > > In my own use case, I think having all the objects from the > > supermodule *and* submodules all be in the same repo is what I want. > > This kind of obviates the need for .gitmodules entirely, if > > git-checkout and friends will do the right thing. I think I'll submit > > some patches eventually once I have this figured out properly. > > Hm. But what about those who might want to pull from you? .git/config > doesn't propagate, which means that they'll be kind of stuck, don't > you think? Not exactly. The idea is that if the supermodule and submodules are all lumped into a single repo (and your refs are set up correctly), then cloning the supermodule will also clone all the submodules. So everyone will have all the necessary refs anyway; as long as git-checkout checks them out, .gitmodules shouldn't have to exist at all, becaues there's nothing "special" for git-submodule to do. Have fun, Avery -- 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
