I suspect you're overtly worried about the fallout of such a disruptive change. If so, you could've just said: "Ram, I like the idea. But what breakages do you estimate we'll have to deal with?" instead of attacking the idea and repeatedly questioning its purpose. So, I'll make a rough guess based on the first iteration I intend to get merged: - Not all the git submodule subcommands will work. add/ status/ init/ deinit are easy to rewrite, but stuff like --recursive and foreach might be slightly problematic as I already pointed out earlier. We'll have to code depending on how far you think the first iteration should go. After a few iterations, we can make 'git submodule' just print "This command is deprecated. Please read `man gitsubmodules`." - All existing repositories with submodules will not be supported. My plan to deal with this: Have git-core code detect commit objects in-tree and disable things like diff. As soon as the user executes the first 'git submodule' command, remove all existing submodules, along with .gitmodules and re-add them as link objects. Then print a message saying: "We've just migrated your submodules to the new format. Please commit this." That's really it. It's certainly not earth-shattering breakage; and I think the inconvenience it causes is more than compensated by its beautiful design and UI/UX. -- 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