Kenneth Lorber <keni@xxxxxxxx> writes: > From: Kenneth Lorber <keni@xxxxxxx> > > Add a file of guidelines to prevent the namespace collisions > mentioned in git help config without any guidance. Collisions with whom are you worried about? Random $stuff the end users want to have the namespace that governs $stuff (where $stuff could be an environment variable, a file on the filesystem, refname in git, etc.)? Random $stuff third-party tools want to add? As far as git is concerned, all the files under $GIT_DIR are blackbox and off-limits from end users and third-party tools, so there is no collisions in "a file on the filesystem", but creating a ref may result in a creation of a file in $GIT_DIR/, and carving out a part of refs/* hierarchy for use by a third-party tool is a worthwhile goal. Just like "git bisect" uses refs/bisect/* for its own operation and wants to reserve the hierarchy from other tools and the end users, any third-party tool would want a similar carve-out. The same for configuration variables. HOWEVER I would rather not to see an arbitrary set of rules that are not battle-tested in the field added to our documentation. Instead, my preference is to add a document that describes what namespaces (e.g. environment variable, reference, configuration varable) third-party tools may want carving out for themselves to raise awareness of writers of such tools, and tell them to talk to us on the list, saying "I plan to write a tool that wants to reserve refs/frotz/ hierarchy for its own use---comments?", so that people can respond with "I know a tool that already uses that hierarchy, so you'd need to come up with a different one" to save hassles of having to rename before it happens. After gaining experience from such exchanges, we might come up a set of rules so that no collisions would be possible without any coordination, and then we could document those rules. I do not think that is plausible to happen, but that is OK.
