John Keeping wrote: > 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. If we want the entire feature list in the very first iteration, it's going to be huge. > 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. That can be implemented in the current submodule system too, fwiw. > 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). Like I've said before: there is nothing that _cannot_ be done with the current submodule system. To see the real advantages of this new submodule system, you have to think like a developer, not an end-user. Focusing just on end-user happiness is a very myopic way to develop software, and I think the git community is better than that. -- 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