From: Junio C Hamano <gitster@pobox.com>
To: Kenneth Lorber <keni@his.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH v2 3/6] doc: Add namespace collision guidelines file
Date: Thu, 28 May 2020 11:49:27 -0700 [thread overview]
Message-ID: <xmqqy2pb3new.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200525232727.21096-4-keni@his.com> (Kenneth Lorber's message of "Mon, 25 May 2020 19:27:24 -0400")
Kenneth Lorber <keni@his.com> writes:
> +Git uses identifiers in a number of different namespaces:
> +
> +* environment variables
> +* files in $GIT_DIR
> +* files in the working trees
> +* config sections
> +* hooks
> +* attributes
The names of the subcommands "git" can spawn is a shared resource.
You can install "git-imerge" program in one of the directories on
your $PATH and say "git imerge" to invoke the program.
Two third-party developers may have to coordinate to avoid giving
the same name to their totally-unrelated tools, if they hope that
both of their tools to be useful in the larger Git ecosystem.
> +In order to reduce the chance of collisions between names Git uses
> +and those used by other entities (users, groups, and extension authors),
> +the following are recommended best practices.
OK.
> +Names reserved to Git:
s/to/by/ perhaps.
> +Names reserved for individual users:
> +
> +* The directory `$GIT_DIR/my`
So an individual user is allowed to store anything in that
directory, and "git" or any third-party tools won't care. OK.
> +* Environment variables starting with `GIT_MY_`
Likewise. But then the users can use MY_FOO_BLAH without GIT_
prefix in the first place, so there isn't much gain there. Downside
for "git" and third-party tool authors is not so big (just the loss
of a single prefix "_MY"), so perhaps it is OK.
> +* Configuration section `my`
> +* Files or directories in `$GIT_DIR/hooks` starting with `my_`
> +* Attributes starting with `my_`
The last one does not make much sense. You have to forbid defining
my_attributes in .gitattributes files that are tracked in-tree;
otherwise I cannot work with you on the same project, because I
cannot use my_attributes for my own purpose in that project. For
the same reason, reserving attributes for individual repositories
does not make much sense, either.
> +Names reserved for individual repos:
> +
> +* The directory `$GIT_DIR/this`
It is unclear what it means to have $GIT_DIR/my and $GIT_DIR/this
and how to choose which one of these two ought to be used for each
occasion a user finds a need to store something in these places.
> +* Environment variables starting with `GIT_THIS_`
The utility of this one is dubious.
$ export GIT_THIS_BLAH=value
$ cd repo1 ; work work work
$ cd ../repo2 ; work work work
Unless you arrange to reset GIT_THIS_* environment variable every
time you visit a separate repository, it would not be pratical to
use.
> +Names reserved for the lowest level group of people:
What's lowest level group of people?
Also, where did the guideline for third-party tools go?
At this point I need to say that this is not very well thought out
(yet), or that this is not very well explained, or perhaps both,
so I'll stop commenting on it for now.
Thanks.
next prev parent reply other threads:[~2020-05-28 18:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-17 2:13 [RFC PATCH 0/6] various documentation bits Kenneth Lorber
2020-05-17 2:13 ` [RFC PATCH 1/6] Tell the glossary about core.hooksPath Kenneth Lorber
2020-05-17 18:33 ` Junio C Hamano
2020-05-18 22:06 ` Kenneth Lorber
2020-05-17 2:13 ` [RFC PATCH 2/6] Add bit on extending git to Hacking Git Kenneth Lorber
2020-05-17 18:34 ` Junio C Hamano
2020-05-18 22:10 ` Kenneth Lorber
2020-05-17 2:13 ` [RFC PATCH 3/6] Add namespace collision avoidance guidelines file Kenneth Lorber
2020-05-17 9:45 ` Abhishek Kumar
2020-05-18 15:51 ` Kenneth Lorber
2020-05-17 15:31 ` Junio C Hamano
2020-05-18 21:46 ` Kenneth Lorber
2020-05-17 2:13 ` [RFC PATCH 4/6] Include NAMESPACE COLLISIONS doc into gitrepository-layout.txt Kenneth Lorber
2020-05-18 0:26 ` Junio C Hamano
2020-05-18 23:54 ` Kenneth Lorber
2020-05-17 2:13 ` [RFC PATCH 5/6] Tell config.txt about NAMESPACE COLLISIONS Kenneth Lorber
2020-05-18 0:32 ` Junio C Hamano
2020-05-17 2:13 ` [RFC PATCH 6/6] Add NAMESPACE COLLISIONS reference to Hacking Git Kenneth Lorber
2020-05-17 7:42 ` [RFC PATCH 0/6] various documentation bits Abhishek Kumar
2020-05-17 18:39 ` Junio C Hamano
2020-05-18 23:44 ` Kenneth Lorber
2020-05-18 15:45 ` Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 " Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 1/6] doc: Tell the glossary about core.hooksPath Kenneth Lorber
2020-05-26 18:59 ` Junio C Hamano
2020-05-27 16:52 ` Kenneth Lorber
2020-05-27 17:18 ` Kenneth Lorber
2020-05-27 17:18 ` Junio C Hamano
2020-05-25 23:27 ` [RFC PATCH v2 2/6] doc: Add bit on extending git to Hacking Git Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 3/6] doc: Add namespace collision guidelines file Kenneth Lorber
2020-05-28 18:49 ` Junio C Hamano [this message]
2020-05-28 19:29 ` Junio C Hamano
2020-05-29 1:20 ` Junio C Hamano
2020-05-29 18:08 ` Junio C Hamano
2020-06-01 23:55 ` Kenneth Lorber
2020-06-01 18:38 ` Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 4/6] doc: Add collision doc to gitrepository-layout.txt Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 5/6] doc: Tell config.txt about namespace collisions Kenneth Lorber
2020-05-25 23:27 ` [RFC PATCH v2 6/6] doc: Add collision reference to Hacking Git Kenneth Lorber
2020-05-31 21:37 ` [RFC PATCH 0/2] update glossary hooks entry Kenneth Lorber
2020-05-31 21:37 ` [RFC PATCH 1/2] doc: Tell the glossary about core.hooksPath Kenneth Lorber
2020-05-31 21:37 ` [RFC PATCH 2/2] doc: remove dated info and refs to sample hooks Kenneth Lorber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy2pb3new.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=keni@his.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).