Brandon Williams <bmw...@google.com> writes: > Introduce a function "strbuf_submodule_gitdir()" which callers can use > to build a path to a submodule's gitdir. This allows for a single > location where we can munge the submodule name (by url encoding it) > before using it as part of a path.
I am not sure about the name with "strbuf_" prefix; it is as bad as using hungarian notation for variable names. There probably are some existing offenders, but it is merely an implementation detail (or a function signature) that the returned value is communicated using a strbuf (contrast it with things like strbuf_add() that is _about_ doing something to a strbuf), and in the longer term I prefer to see them lose "strbuf_" from their names and optionally use the same number of bytes to describe what they do more clearly. For this particular case, "submodule" and "gitdir" are sufficient to signal what the function is about, I think, so the "optionally use..." is not necessary---instead we get a name that is shorte to type and to remember. > Using submodule names as is continues to be not such a good idea. Maybe > we could apply something like this to stop using them as is. url > encoding seems like the easiest approach, but I've also heard > suggestions that would could use the SHA1 of the submodule name. Being human readable is a good trait to keep when possible. When you have two submodules with vastly different names (e.g. "hello" and "bye"), and for some reason you need to go in to .gitmodules and manually fix their entries up, "hash of name" does not help you avoid mistakes (hashing "hello" and hashing "helo" would give a name as different as hashing "bye", so when you see [module "hel$something"] in .gitmodules, you would know that entry is not about the "bye" module, but "hello" module, even if you do not remember exactly if the module you want to manipulate was called "hello" or "helo"). The same discussion applies against UUID.
