John Keeping wrote: > So not a flag day, but still some point at which the repository > transitions to "will not work with Git older than version X". And if > you need to add a new submodule then you cannot delay that transition > any longer. Yes, that is true. I don't see any way out of this. > I haven't seen anywhere a concise list of what functionality this is. > Do you have a simple bulleted list of what new features this would > allow? Sure, I'll write it out for you from an end-user perspective: 0. Great UI/UX. No more cd-to-toplevel, and a beautiful set of native commands that are consistent with the overall design of git-core. Which means: clone (to put something in an unstaged place), add (to stage), and commit (to commit the change). There's now exactly one place in your worktree (which is represented as one file in git; think of it a sort of symlink) to look in for all the information. git cat-link <link> to figure out its parameters, git edit-link to edit its parameters: no more "find the matching pwd in .gitmodules in toplevel". To remove a submodule, just git rm. And git mv works! 1. True floating submodules. You can have a submodule checked out at `master` or `v3.1`: no more detached HEADs in submodules unless you want fixed submodules. No additional cruft required to do the floating: the information is native, in a link object. 2. Initializing a nested submodule without having to initialize the outer one: no more repo XML nonsense. And it's composable: you don't need to put the information about all submodules in one central place. 3. Ability to have very many large submodule repositories without the performance hit. It makes sense to block stat() from going through when you have floating submodules. This means that many levels of nesting are very easily possible. 4. It's suddenly much easier to add new features to this implementation. You don't need to do the kind of gymnastics you'd have to do if you were hacking on submodule.c/ git-submodule.sh. This is basically how "great design" plays out. -- 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