Stefan Beller <sbel...@google.com> writes: > I claim that the exposure into .gitmodules combined with > the extreme similarity to its path is confusing. Maybe this > can be fixed by a different default name.
I think that this may be worth thinking about it further. The names are something the end users are not supposed to change, and one way to ensure that is to make .gitmodules file a binary black box that can only be updated with a specialized tool---as long as the tool does not allow updating the "name" field, you wouldn't risk them mucking with it. Limiting the update to a specialized tool also would give us a single place to ensure that it is globally unique across the history of the project (well, at least the part of the history that is visible to your repository). Of course, being "one way" to do so does not mean it is the only way, or it is the best way. Keeping the information in a text file lets you merge them more easily when you add a submodule B while I added a submodule C, for example, and having a human readble name lets us learn from the output of "git log -p .gitmodules" that the repository of the "linux-kernel" submodule we use in our appliance used to live at linux-2.6.git but has moved to linux.git over time (for the latter use case to work well, we cannot change the name to something unreadable by humans like uuid---discouraging people from modifying and making them unreadble are two different things).
