On Fri, 2010-07-23 at 07:54 +0100, Will Palmer wrote: > The problem is that, unlike so much of git, submodules make themselves > known. They're loud, they're in the way, they require management to > work. Case in point: > "Switching from 1.7.2 to this tree will of course give you a tree > without gitk and git-gui (nothing a simple "git submodule init/update" > cannot fix)" > > So already in order to build a working git again, someone needs to > manually run some extra commands, which could potentially (but not [...] There's a relatively comprehensive list of TODO items on the git wiki along with the summer of code ideas page. They have been known for some time, but up till now most people have just worked around them. I think using it for git-core would possibly assist in creating the anger that some of these changes will need to be performed in to be of greater benefit to the community as a whole ;-) submodules are nice; it's good for instance to be able to keep unrelated parts of the project out of the history view, squashed in the main project yet still fine-grained and bisectable in the sub-project. While I haven't gone through the other people who have described their use cases/requirements in detail, it strikes me that many of the existing ideas would help these requirements be met too. Sam -- 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