Great release. Submodules are bad practice riddled with problems, I think it wouldn't be bad to remove this feature at all, that way no-one will be have an option to use it.
From what I've gathered skimming the numerous blog posts venting about submodules, it seems that people have trouble with submodules because they are trying to integrate them into a workflow they work poorly in (i.e., rapidly changing modules). There seems to be room for improvement for that type of usage, given what people are saying, but I wonder if there have been any changes to submodules since those posts (many of them are dated around 2011-2012).
My own positive experience with submodules involves dependencies that only occasionally change; I can always point to a specific tag that should be used.
Even if the interface is stabilized, when you update implementation of a submodule you will still have to recursively update all submodules from main down to the changed module.
How do you share code between projects/teams then?
How do you work on several branches simultaneously, each of them requiring a different version of their dependencies?
How do you handle submodules having the same version of their dependencies (diamond dependencies)? You will get tons of, not just redundant, but also conflicting duplicates. In many environments include dirs and such dont follow the file system hierarchy.
Git is not a package manager, don't make the mistake of trying to use it as one.
