Stefan Beller <sbel...@google.com> writes: > So you propose to make git-add behave like "git submodule add" > (i.e. also add the .gitmodules entry for name/path/URL), which I > like from a submodule perspective. > > However other users of gitlinks might be confused[1], which is why > I refrained from "making every gitlink into a submodule". Specifically > the more powerful a submodule operation is (the more fluff adds), > the harder it should be for people to mis-use it.
A few questions that come to mind are: - Does "git add sub/" have enough information to populate .gitmodules? If we have reasonable "default" values for .gitmodules entries (e.g. missing URL means we won't fetch when asked to go recursively fetch), perhaps we can leave everything other than "submodule.$name.path" undefined. - Can't we help those who have gitlinks without .gitmodules entries exactly the same way as above, i.e. when we see a gitlink and try to treat it as a submodule, we'd first try to look it up from .gitmodules (by going from path to name and then to submodule.$name.$var); the above "'git add sub/' would add an entry for .gitmodules" wish is based on the assumption that there are reasonable "default" values for each of these $var--so by basing on the same assumption, we can "pretend" as if these submodule.$name.$var were in .gitmodules file when we see gitlinks without .gitmodules entries. IOW, if "git add sub/" can add .gitmodules to help people without having to type "git submodule add sub/", then we can give exactly the same degree of help without even modifying .gitmodules when "git add sub/" is run. - Even if we could solve it with "git add sub/" that adds to .gitmodules, is it a good solution, when we can solve the same thing without having to do so?
