Re: [RFC PATCH 3/6] Add namespace collision avoidance guidelines file

From: Junio C Hamano <gitster@pobox.com>
To: Kenneth Lorber <keni@hers.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 3/6] Add namespace collision avoidance guidelines file
Date: Sun, 17 May 2020 08:31:00 -0700	[thread overview]
Message-ID: <xmqqh7we7f4b.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <1589681624-36969-4-git-send-email-keni@hers.com> (Kenneth Lorber's message of "Sat, 16 May 2020 22:13:41 -0400")

Kenneth Lorber <keni@hers.com> writes:

> From: Kenneth Lorber <keni@his.com>
>
> 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.