Am 28.03.2013 10:16, schrieb Ramkumar Ramachandra: > 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. Guess what: submodules are the solution for a certain set of use cases, and tools like subtree are a solution for another set of use cases. There is no silver bullet. >> 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). There was discussion about what to record in the index/commit of the superproject in early submodule days (some time before I became involved in Git, seems I currently cannot find a link to that). A commit is the thing to record here because it *is* the perfect fit, as some years of submodule experience show. >> 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. You cannot simply change the fundamental assumptions of submodules and expect them to be the same thing afterwards. And it doesn't matter at all if we "fix all the problems in shell" or in C-code, we'll fix the remaining problems that are fixable in whatever part of Git it makes sense. And I don't have the impression you have an idea about what submodules are good at, where they can be improved and what problems they'll probably never solve. >> 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. Please go ahead, but if your goal is "to make our shell hackery easier" I'm not interested. I want to improve the user experience of submodules and don't care much in what language we achieve that. And I can't see anything fundamental being wrong with submodules but strongly believe they are a perfect match for some very important use cases (some of which I see happening at my $dayjob for some years now), so I still don't see what you are trying to "fix" here. -- 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