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
- 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html