2010-01-28 10:50:20 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='test various @{X} syntax combinations together'
|
2020-11-19 00:44:21 +01:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2010-01-28 10:50:20 +01:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
check() {
|
2013-05-07 23:55:02 +02: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 09:31:57 +01:00
|
|
|
elif test '$2' = 'ref'
|
|
|
|
then
|
2013-05-07 23:55:02 +02: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 09:31:57 +01:00
|
|
|
else
|
|
|
|
git cat-file -p '$1' >actual
|
2013-05-07 23:55:02 +02:00
|
|
|
fi &&
|
|
|
|
test_cmp expect actual
|
|
|
|
"
|
2010-01-28 10:50:20 +01:00
|
|
|
}
|
2013-05-07 23:55:02 +02:00
|
|
|
|
2010-01-28 10:50:20 +01:00
|
|
|
nonsense() {
|
2013-05-07 23:55:02 +02:00
|
|
|
test_expect_${2:-success} "$1 is nonsensical" "
|
2013-05-07 23:55:03 +02:00
|
|
|
test_must_fail git rev-parse --verify '$1'
|
2013-05-07 23:55:02 +02:00
|
|
|
"
|
2010-01-28 10:50:20 +01:00
|
|
|
}
|
2013-05-07 23:55:02 +02:00
|
|
|
|
2010-01-28 10:50:20 +01:00
|
|
|
fail() {
|
|
|
|
"$@" failure
|
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
2020-11-19 00:44:21 +01:00
|
|
|
test_commit main-one &&
|
|
|
|
test_commit main-two &&
|
2010-01-28 10:50:20 +01:00
|
|
|
git checkout -b upstream-branch &&
|
|
|
|
test_commit upstream-one &&
|
|
|
|
test_commit upstream-two &&
|
2016-01-27 17:19:52 +01:00
|
|
|
if test_have_prereq !MINGW
|
|
|
|
then
|
|
|
|
git checkout -b @/at-test
|
|
|
|
fi &&
|
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 08:34:30 +02:00
|
|
|
git checkout -b @@/at-test &&
|
|
|
|
git checkout -b @at-test &&
|
2010-01-28 10:50:20 +01: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 &&
|
2020-11-19 00:44:21 +01:00
|
|
|
git branch -u main old-branch &&
|
2013-05-07 23:55:01 +02:00
|
|
|
git branch -u upstream-branch new-branch
|
2010-01-28 10:50:20 +01:00
|
|
|
'
|
|
|
|
|
2013-05-07 23:55:02 +02:00
|
|
|
check HEAD ref refs/heads/new-branch
|
|
|
|
check "@{1}" commit new-one
|
2013-05-07 23:55:04 +02:00
|
|
|
check "HEAD@{1}" commit new-one
|
|
|
|
check "@{now}" commit new-two
|
|
|
|
check "HEAD@{now}" commit new-two
|
2013-05-07 23:55:02 +02:00
|
|
|
check "@{-1}" ref refs/heads/old-branch
|
2013-05-07 23:55:04 +02:00
|
|
|
check "@{-1}@{0}" commit old-two
|
2013-05-07 23:55:02 +02:00
|
|
|
check "@{-1}@{1}" commit old-one
|
|
|
|
check "@{u}" ref refs/heads/upstream-branch
|
2013-05-07 23:55:04 +02:00
|
|
|
check "HEAD@{u}" ref refs/heads/upstream-branch
|
2013-05-07 23:55:02 +02:00
|
|
|
check "@{u}@{1}" commit upstream-one
|
2020-11-19 00:44:21 +01:00
|
|
|
check "@{-1}@{u}" ref refs/heads/main
|
|
|
|
check "@{-1}@{u}@{1}" commit main-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 08:34:30 +02:00
|
|
|
check "@" commit new-two
|
|
|
|
check "@@{u}" ref refs/heads/upstream-branch
|
|
|
|
check "@@/at-test" ref refs/heads/@@/at-test
|
2016-01-27 17:19:52 +01:00
|
|
|
test_have_prereq MINGW ||
|
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 08:34:30 +02:00
|
|
|
check "@/at-test" ref refs/heads/@/at-test
|
|
|
|
check "@at-test" ref refs/heads/@at-test
|
2010-01-28 10:56:43 +01:00
|
|
|
nonsense "@{u}@{-1}"
|
2013-05-07 23:55:04 +02:00
|
|
|
nonsense "@{0}@{0}"
|
2010-01-28 10:50:20 +01:00
|
|
|
nonsense "@{1}@{u}"
|
2013-05-07 23:55:04 +02:00
|
|
|
nonsense "HEAD@{-1}"
|
|
|
|
nonsense "@{-1}@{-1}"
|
2010-01-28 10:50:20 +01:00
|
|
|
|
2013-05-07 23:55:05 +02: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 09:31:57 +01: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
|
|
|
|
|
2021-01-07 11:36:59 +01:00
|
|
|
test_expect_success '@{1} works with only one reflog entry' '
|
2021-01-25 23:19:18 +01:00
|
|
|
git checkout -B newbranch main &&
|
2021-01-07 11:36:59 +01:00
|
|
|
git reflog expire --expire=now refs/heads/newbranch &&
|
|
|
|
git commit --allow-empty -m "first after expiration" &&
|
|
|
|
test_cmp_rev newbranch~ newbranch@{1}
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '@{0} works with empty reflog' '
|
2021-01-25 23:19:18 +01:00
|
|
|
git checkout -B newbranch main &&
|
2021-01-07 11:36:59 +01:00
|
|
|
git reflog expire --expire=now refs/heads/newbranch &&
|
|
|
|
test_cmp_rev newbranch newbranch@{0}
|
|
|
|
'
|
|
|
|
|
2010-01-28 10:50:20 +01:00
|
|
|
test_done
|