Jens Lehmann wrote: > Unless you acknowledge that submodules are a different repo, you'll > always run into problems. I believe future enhancements will make > this less tedious, but in the end they will stay separate repos > (which is the whole point, you'd want to use a different approach > - e.g. subtree - if you want to put stuff from different upstreams > into a single repo without keeping the distinction where all that > came from). I acknowledge that it's a different repository. It's just that I think that our current design has too many seams: why do you think it's impossible to make it seamless? git-subtree is not an answer to anything. Dumping all the history into one repository has its limited usecases, but it is no solution. > What else than a commit object should that be??? Submodules are > there to have a different upstream for a part of your work tree, > and that means a commit in that repo is the only sane thing to > record in the superproject. A lot of thought has been put into > this, and it is definitely a good choice [1]. Linus argues that it shouldn't be a tree object, and I agree with that. I don't see an argument that says that the commit object is a perfect fit (probably because it's not). > How? The "submodules suck, we should try a completely different > approach" thingy comes up from time to time, but so far nobody > could provide a viable alternative to what we currently do. My argument is not "submodules suck; we should throw them out of the window, and start from scratch" at all. I'm merely questioning the fundamental assumptions that submodules make, instead of proposing that we work around everything in shell. We don't have to be married to the existing implementation of submodules and try to fix all the problems in shell. > And apart from that, let's not forget we identified some valuable > improvements to submodules in this thread: > [...] > All of those are topics I like to see materialize, and you are > welcome to tackle them. Allow me a few days to think about changing the fundamental building blocks to make our shell hackery easier. Thanks. -- 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