After the previous round of input:
The intention of this patch series is to make sure, that you always
might use "refs/<something>" to unambiguously refer to a specific
reference.
Or put in another way: With this patch series, refnames for "git log",
starting with "refs/" should never result in a
warning: refname '...' is ambiguous.
Exceptions:
You already have strangely named references in your repository.
You pull such strangely named references from a remote repository.
This patch series does not prevent you from creating various other
forms of ambiguous refnames. Example:
git branch origin/master
This will very likely result in an ambiguity, because now the
references
refs/heads/origin/master
refs/remotes/origin/master
will very likely both exist. "origin/master" matches both refnames.
This patch series forbids to create new reference names, which start
with "refs" or "refs/*" with the commands
git branch <name>
git checkout -b <name>
git tag <name>
git remote add <name>
Note: This patch does NOT prevent you from working with references
which already exist. It just prevents you from creating new ones
with the commands listed above.
That's also the reason why the '--force' option is not evaluated here.
I cannot think of a good reason, why you ever should want to create
refnames matching any of the following patterns:
refs/heads/refs/*
refs/tags/refs/*
refs/remotes/refs/*
Ingo Rohloff (4):
refs: new function newname_has_bad_prefix
branch: Prevent creation of local branches named "refs" or "refs/*"
remote: Prevent users from creating remotes named "refs" or "refs/*"
tag: Prevent users from creating tags named "refs" or "refs/*"
builtin/branch.c | 6 ++++++
builtin/checkout.c | 3 +++
builtin/remote.c | 3 +++
builtin/tag.c | 3 +++
refs.c | 30 ++++++++++++++++++++++++++++++
refs.h | 2 ++
6 files changed, 47 insertions(+)
--
2.24.0
