2010-01-28 09:50:20 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test various @{X} syntax combinations together'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
check() {
|
2013-05-07 21:55:02 +00:00
|
|
|
test_expect_${4:-success} "$1 = $3" "
|
|
|
|
|
echo '$3' >expect &&
|
|
|
|
|
if test '$2' = 'commit'
|
|
|
|
|
then
|
|
|
|
|
git log -1 --format=%s '$1' >actual
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 08:31:57 +00:00
|
|
|
elif test '$2' = 'ref'
|
|
|
|
|
then
|
2013-05-07 21:55:02 +00:00
|
|
|
git rev-parse --symbolic-full-name '$1' >actual
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 08:31:57 +00:00
|
|
|
else
|
|
|
|
|
git cat-file -p '$1' >actual
|
2013-05-07 21:55:02 +00:00
|
|
|
fi &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
"
|
2010-01-28 09:50:20 +00:00
|
|
|
}
|
2013-05-07 21:55:02 +00:00
|
|
|
|
2010-01-28 09:50:20 +00:00
|
|
|
nonsense() {
|
2013-05-07 21:55:02 +00:00
|
|
|
test_expect_${2:-success} "$1 is nonsensical" "
|
2013-05-07 21:55:03 +00:00
|
|
|
test_must_fail git rev-parse --verify '$1'
|
2013-05-07 21:55:02 +00:00
|
|
|
"
|
2010-01-28 09:50:20 +00:00
|
|
|
}
|
2013-05-07 21:55:02 +00:00
|
|
|
|
2010-01-28 09:50:20 +00:00
|
|
|
fail() {
|
|
|
|
|
"$@" failure
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
test_commit master-one &&
|
|
|
|
|
test_commit master-two &&
|
|
|
|
|
git checkout -b upstream-branch &&
|
|
|
|
|
test_commit upstream-one &&
|
|
|
|
|
test_commit upstream-two &&
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 06:34:30 +00:00
|
|
|
git checkout -b @/at-test &&
|
|
|
|
|
git checkout -b @@/at-test &&
|
|
|
|
|
git checkout -b @at-test &&
|
2010-01-28 09:50:20 +00:00
|
|
|
git checkout -b old-branch &&
|
|
|
|
|
test_commit old-one &&
|
|
|
|
|
test_commit old-two &&
|
|
|
|
|
git checkout -b new-branch &&
|
|
|
|
|
test_commit new-one &&
|
|
|
|
|
test_commit new-two &&
|
2013-05-07 21:55:01 +00:00
|
|
|
git branch -u master old-branch &&
|
|
|
|
|
git branch -u upstream-branch new-branch
|
2010-01-28 09:50:20 +00:00
|
|
|
'
|
|
|
|
|
|
2013-05-07 21:55:02 +00:00
|
|
|
check HEAD ref refs/heads/new-branch
|
|
|
|
|
check "@{1}" commit new-one
|
2013-05-07 21:55:04 +00:00
|
|
|
check "HEAD@{1}" commit new-one
|
|
|
|
|
check "@{now}" commit new-two
|
|
|
|
|
check "HEAD@{now}" commit new-two
|
2013-05-07 21:55:02 +00:00
|
|
|
check "@{-1}" ref refs/heads/old-branch
|
2013-05-07 21:55:04 +00:00
|
|
|
check "@{-1}@{0}" commit old-two
|
2013-05-07 21:55:02 +00:00
|
|
|
check "@{-1}@{1}" commit old-one
|
|
|
|
|
check "@{u}" ref refs/heads/upstream-branch
|
2013-05-07 21:55:04 +00:00
|
|
|
check "HEAD@{u}" ref refs/heads/upstream-branch
|
2013-05-07 21:55:02 +00:00
|
|
|
check "@{u}@{1}" commit upstream-one
|
|
|
|
|
check "@{-1}@{u}" ref refs/heads/master
|
|
|
|
|
check "@{-1}@{u}@{1}" commit master-one
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 06:34:30 +00:00
|
|
|
check "@" commit new-two
|
|
|
|
|
check "@@{u}" ref refs/heads/upstream-branch
|
|
|
|
|
check "@@/at-test" ref refs/heads/@@/at-test
|
|
|
|
|
check "@/at-test" ref refs/heads/@/at-test
|
|
|
|
|
check "@at-test" ref refs/heads/@at-test
|
2010-01-28 09:56:43 +00:00
|
|
|
nonsense "@{u}@{-1}"
|
2013-05-07 21:55:04 +00:00
|
|
|
nonsense "@{0}@{0}"
|
2010-01-28 09:50:20 +00:00
|
|
|
nonsense "@{1}@{u}"
|
2013-05-07 21:55:04 +00:00
|
|
|
nonsense "HEAD@{-1}"
|
|
|
|
|
nonsense "@{-1}@{-1}"
|
2010-01-28 09:50:20 +00:00
|
|
|
|
2013-05-07 21:55:05 +00:00
|
|
|
# @{N} versus HEAD@{N}
|
|
|
|
|
|
|
|
|
|
check "HEAD@{3}" commit old-two
|
|
|
|
|
nonsense "@{3}"
|
|
|
|
|
|
|
|
|
|
test_expect_success 'switch to old-branch' '
|
|
|
|
|
git checkout old-branch
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
check HEAD ref refs/heads/old-branch
|
|
|
|
|
check "HEAD@{1}" commit new-two
|
|
|
|
|
check "@{1}" commit old-one
|
|
|
|
|
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 08:31:57 +00:00
|
|
|
test_expect_success 'create path with @' '
|
|
|
|
|
echo content >normal &&
|
|
|
|
|
echo content >fun@ny &&
|
|
|
|
|
git add normal fun@ny &&
|
|
|
|
|
git commit -m "funny path"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
check "@:normal" blob content
|
|
|
|
|
check "@:fun@ny" blob content
|
|
|
|
|
|
2010-01-28 09:50:20 +00:00
|
|
|
test_done
|