remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='refspec parsing'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_refspec () {
|
|
|
|
|
kind=$1 refspec=$2 expect=$3
|
|
|
|
|
git config remote.frotz.url "." &&
|
|
|
|
|
git config --remove-section remote.frotz &&
|
|
|
|
|
git config remote.frotz.url "." &&
|
|
|
|
|
git config "remote.frotz.$kind" "$refspec" &&
|
|
|
|
|
if test "$expect" != invalid
|
|
|
|
|
then
|
|
|
|
|
title="$kind $refspec"
|
|
|
|
|
test='git ls-remote frotz'
|
|
|
|
|
else
|
|
|
|
|
title="$kind $refspec (invalid)"
|
|
|
|
|
test='test_must_fail git ls-remote frotz'
|
|
|
|
|
fi
|
|
|
|
|
test_expect_success "$title" "$test"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_refspec push '' invalid
|
2008-04-28 17:32:12 +02:00
|
|
|
test_refspec push ':'
|
|
|
|
|
test_refspec push '::' invalid
|
|
|
|
|
test_refspec push '+:'
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
|
|
|
|
|
test_refspec fetch ''
|
|
|
|
|
test_refspec fetch ':'
|
2008-04-28 17:32:12 +02:00
|
|
|
test_refspec fetch '::' invalid
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
|
|
|
|
|
test_refspec push 'refs/heads/*:refs/remotes/frotz/*'
|
|
|
|
|
test_refspec push 'refs/heads/*:refs/remotes/frotz' invalid
|
|
|
|
|
test_refspec push 'refs/heads:refs/remotes/frotz/*' invalid
|
2020-11-19 00:44:32 +01:00
|
|
|
test_refspec push 'refs/heads/main:refs/remotes/frotz/xyzzy'
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# These have invalid LHS, but we do not have a formal "valid sha-1
|
|
|
|
|
# expression syntax checker" so they are not checked with the current
|
|
|
|
|
# code. They will be caught downstream anyway, but we may want to
|
|
|
|
|
# have tighter check later...
|
|
|
|
|
|
2020-11-19 00:44:32 +01:00
|
|
|
: test_refspec push 'refs/heads/main::refs/remotes/frotz/xyzzy' invalid
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
: test_refspec push 'refs/heads/maste :refs/remotes/frotz/xyzzy' invalid
|
|
|
|
|
|
|
|
|
|
test_refspec fetch 'refs/heads/*:refs/remotes/frotz/*'
|
|
|
|
|
test_refspec fetch 'refs/heads/*:refs/remotes/frotz' invalid
|
|
|
|
|
test_refspec fetch 'refs/heads:refs/remotes/frotz/*' invalid
|
2020-11-19 00:44:32 +01:00
|
|
|
test_refspec fetch 'refs/heads/main:refs/remotes/frotz/xyzzy'
|
|
|
|
|
test_refspec fetch 'refs/heads/main::refs/remotes/frotz/xyzzy' invalid
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
test_refspec fetch 'refs/heads/maste :refs/remotes/frotz/xyzzy' invalid
|
|
|
|
|
|
2020-11-19 00:44:32 +01:00
|
|
|
test_refspec push 'main~1:refs/remotes/frotz/backup'
|
|
|
|
|
test_refspec fetch 'main~1:refs/remotes/frotz/backup' invalid
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
test_refspec push 'HEAD~4:refs/remotes/frotz/new'
|
|
|
|
|
test_refspec fetch 'HEAD~4:refs/remotes/frotz/new' invalid
|
|
|
|
|
|
|
|
|
|
test_refspec push 'HEAD'
|
|
|
|
|
test_refspec fetch 'HEAD'
|
2020-11-26 01:16:16 +01:00
|
|
|
test_refspec push '@'
|
|
|
|
|
test_refspec fetch '@'
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
test_refspec push 'refs/heads/ nitfol' invalid
|
|
|
|
|
test_refspec fetch 'refs/heads/ nitfol' invalid
|
|
|
|
|
|
|
|
|
|
test_refspec push 'HEAD:' invalid
|
|
|
|
|
test_refspec fetch 'HEAD:'
|
|
|
|
|
test_refspec push 'refs/heads/ nitfol:' invalid
|
|
|
|
|
test_refspec fetch 'refs/heads/ nitfol:' invalid
|
|
|
|
|
|
|
|
|
|
test_refspec push ':refs/remotes/frotz/deleteme'
|
|
|
|
|
test_refspec fetch ':refs/remotes/frotz/HEAD-to-me'
|
|
|
|
|
test_refspec push ':refs/remotes/frotz/delete me' invalid
|
|
|
|
|
test_refspec fetch ':refs/remotes/frotz/HEAD to me' invalid
|
|
|
|
|
|
2015-07-22 23:05:33 +02:00
|
|
|
test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah'
|
|
|
|
|
test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah'
|
2009-03-07 07:11:39 +01:00
|
|
|
|
2015-07-22 23:05:33 +02:00
|
|
|
test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*'
|
|
|
|
|
test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*'
|
2009-03-07 07:11:39 +01:00
|
|
|
|
|
|
|
|
test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
|
|
|
|
|
test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
|
|
|
|
|
|
2015-07-22 23:05:33 +02:00
|
|
|
test_refspec fetch 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid
|
|
|
|
|
test_refspec push 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid
|
|
|
|
|
|
2009-03-07 07:11:39 +01:00
|
|
|
test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*'
|
|
|
|
|
test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*'
|
|
|
|
|
|
2014-06-04 05:38:10 +02:00
|
|
|
good=$(printf '\303\204')
|
|
|
|
|
test_refspec fetch "refs/heads/${good}"
|
|
|
|
|
bad=$(printf '\011tab')
|
|
|
|
|
test_refspec fetch "refs/heads/${bad}" invalid
|
|
|
|
|
|
remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:
$ git push origin HEAD~12:master
The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there. For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec. To validate them correctly, the
caller needs to be able to say which kind of refspecs they are. It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.
This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).
This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:
$ git push ../test.git ':/remote.c: Fix overtight refspec:master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-21 07:34:37 +01:00
|
|
|
test_done
|