On Sun, Apr 07, 2013 at 08:34:27PM +0200, Jens Lehmann wrote: > The whole feature list is full of red herrings like this which > have nothing to do with the advantages of a new object, but talk > about UI issues which are easy to solve in both worlds. With the clarifications Ram's provided in this thread, I think there are also some important regressions in functionality in his proposal (at least as it currently stands), particularly losing the .gitconfig overrides. The only proposed change that seems to me to be impossible with the current .gitmodules approach is the "submodule in a non-initialized submodule" feature, but I've never seen anyone ask for that and it seems likely to open a whole can of worms where the behaviour is likely to vary with $PWD. The current hierarchical approach provides sensible encapsulation of repositories and is simple to understand: once you're in a repository nothing above its root directory affects you. It doesn't seem to me that "it's harder than I'd like to add a feature I want" is a good reason to subject all users of submodules to a lot of pain migrating to some new implementation that doesn't work the way they're used to and which will mean they have to deal with complaints when people using an older version of Git can't clone their repository (and I doubt we want this mailing list to be flooded with such complaints either). -- 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