|
|
|
|
git-check-ref-format(1)
|
|
|
|
|
=======================
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
|
|
|
|
git-check-ref-format - Ensures that a reference name is well formed
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
|
|
|
|
[verse]
|
|
|
|
|
'git check-ref-format' <refname>
|
|
|
|
|
'git check-ref-format' [--branch] <branchname-shorthand>
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
|
|
|
|
Checks if a given 'refname' is acceptable, and exits with a non-zero
|
|
|
|
|
status if it is not.
|
|
|
|
|
|
|
|
|
|
A reference is used in git to specify branches and tags. A
|
|
|
|
|
branch head is stored under the `$GIT_DIR/refs/heads` directory, and
|
|
|
|
|
a tag is stored under the `$GIT_DIR/refs/tags` directory. git
|
|
|
|
|
imposes the following rules on how references are named:
|
|
|
|
|
|
|
|
|
|
. They can include slash `/` for hierarchical (directory)
|
|
|
|
|
grouping, but no slash-separated component can begin with a
|
|
|
|
|
dot `.`.
|
|
|
|
|
|
|
|
|
|
. They must contain at least one `/`. This enforces the presence of a
|
|
|
|
|
category like `heads/`, `tags/` etc. but the actual names are not
|
|
|
|
|
restricted.
|
|
|
|
|
|
|
|
|
|
. They cannot have two consecutive dots `..` anywhere.
|
|
|
|
|
|
|
|
|
|
. They cannot have ASCII control characters (i.e. bytes whose
|
|
|
|
|
values are lower than \040, or \177 `DEL`), space, tilde `~`,
|
|
|
|
|
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
|
|
|
|
|
or open bracket `[` anywhere.
|
|
|
|
|
|
check_ref_format(): tighten refname rules
This changes the rules for refnames to forbid:
(1) a refname that contains "@{" in it.
Some people and foreign SCM converter may have named their branches
as frotz@24 and we still want to keep supporting it.
However, "git branch frotz@{24}" is a disaster. It cannot even
checked out because "git checkout frotz@{24}" will interpret it as
"detach the HEAD at twenty-fourth reflog entry of the frotz branch".
(2) a refname that ends with a dot.
We already reject a path component that begins with a dot, primarily
to avoid ambiguous range interpretation. If we allowed ".B" as a
valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
"either in A or B but not in both".
But for this to be complete, we need also to forbid "A." to avoid "in
B but not in A-dot". This was not a problem in the original range
notation, but we should have added this restriction when three-dot
notation was introduced.
Unlike "no dot at the beginning of any path component" rule, this
rule does not have to be "no dot at the end of any path component",
because you cannot abbreviate the tail end away, similar to you can
say "dot-B" to mean "refs/heads/dot-B".
For these reasons, it is not likely people created branches with these
names on purpose, but we have allowed such names to be used for quite some
time, and it is possible that people created such branches by mistake or
by accident.
To help people with branches with such unfortunate names to recover,
we still allow "branch -d 'bad.'" to delete such branches, and also allow
"branch -m bad. good" to rename them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
. They cannot end with a slash `/` nor a dot `.`.
|
|
|
|
|
|
|
|
|
|
. They cannot end with the sequence `.lock`.
|
|
|
|
|
|
check_ref_format(): tighten refname rules
This changes the rules for refnames to forbid:
(1) a refname that contains "@{" in it.
Some people and foreign SCM converter may have named their branches
as frotz@24 and we still want to keep supporting it.
However, "git branch frotz@{24}" is a disaster. It cannot even
checked out because "git checkout frotz@{24}" will interpret it as
"detach the HEAD at twenty-fourth reflog entry of the frotz branch".
(2) a refname that ends with a dot.
We already reject a path component that begins with a dot, primarily
to avoid ambiguous range interpretation. If we allowed ".B" as a
valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
"either in A or B but not in both".
But for this to be complete, we need also to forbid "A." to avoid "in
B but not in A-dot". This was not a problem in the original range
notation, but we should have added this restriction when three-dot
notation was introduced.
Unlike "no dot at the beginning of any path component" rule, this
rule does not have to be "no dot at the end of any path component",
because you cannot abbreviate the tail end away, similar to you can
say "dot-B" to mean "refs/heads/dot-B".
For these reasons, it is not likely people created branches with these
names on purpose, but we have allowed such names to be used for quite some
time, and it is possible that people created such branches by mistake or
by accident.
To help people with branches with such unfortunate names to recover,
we still allow "branch -d 'bad.'" to delete such branches, and also allow
"branch -m bad. good" to rename them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
. They cannot contain a sequence `@{`.
|
|
|
|
|
|
|
|
|
|
- They cannot contain a `\\`.
|
|
|
|
|
|
|
|
|
|
These rules make it easy for shell script based tools to parse
|
|
|
|
|
reference names, pathname expansion by the shell when a reference name is used
|
|
|
|
|
unquoted (by mistake), and also avoids ambiguities in certain
|
|
|
|
|
reference name expressions (see linkgit:git-rev-parse[1]):
|
|
|
|
|
|
|
|
|
|
. A double-dot `..` is often used as in `ref1..ref2`, and in some
|
|
|
|
|
contexts this notation means `{caret}ref1 ref2` (i.e. not in
|
|
|
|
|
`ref1` and in `ref2`).
|
|
|
|
|
|
|
|
|
|
. A tilde `~` and caret `{caret}` are used to introduce the postfix
|
|
|
|
|
'nth parent' and 'peel onion' operation.
|
|
|
|
|
|
|
|
|
|
. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
|
|
|
|
|
value and store it in dstref" in fetch and push operations.
|
|
|
|
|
It may also be used to select a specific object such as with
|
|
|
|
|
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
|
|
|
|
|
|
check_ref_format(): tighten refname rules
This changes the rules for refnames to forbid:
(1) a refname that contains "@{" in it.
Some people and foreign SCM converter may have named their branches
as frotz@24 and we still want to keep supporting it.
However, "git branch frotz@{24}" is a disaster. It cannot even
checked out because "git checkout frotz@{24}" will interpret it as
"detach the HEAD at twenty-fourth reflog entry of the frotz branch".
(2) a refname that ends with a dot.
We already reject a path component that begins with a dot, primarily
to avoid ambiguous range interpretation. If we allowed ".B" as a
valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
"either in A or B but not in both".
But for this to be complete, we need also to forbid "A." to avoid "in
B but not in A-dot". This was not a problem in the original range
notation, but we should have added this restriction when three-dot
notation was introduced.
Unlike "no dot at the beginning of any path component" rule, this
rule does not have to be "no dot at the end of any path component",
because you cannot abbreviate the tail end away, similar to you can
say "dot-B" to mean "refs/heads/dot-B".
For these reasons, it is not likely people created branches with these
names on purpose, but we have allowed such names to be used for quite some
time, and it is possible that people created such branches by mistake or
by accident.
To help people with branches with such unfortunate names to recover,
we still allow "branch -d 'bad.'" to delete such branches, and also allow
"branch -m bad. good" to rename them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
. at-open-brace `@{` is used as a notation to access a reflog entry.
|
|
|
|
|
|
|
|
|
|
With the `--branch` option, it expands a branch name shorthand and
|
|
|
|
|
prints the name of the branch the shorthand refers to.
|
|
|
|
|
|
|
|
|
|
EXAMPLE
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
git check-ref-format --branch @{-1}::
|
|
|
|
|
|
|
|
|
|
Print the name of the previous branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GIT
|
|
|
|
|
---
|
|
|
|
|
Part of the linkgit:git[1] suite
|
