2008-03-04 03:27:20 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2008-09-03 08:59:29 +00:00
|
|
|
test_description='git pack-object --include-tag'
|
2020-11-18 23:44:29 +00: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-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2008-03-04 03:27:20 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
2015-12-23 13:45:51 +00:00
|
|
|
TRASH=$(pwd)
|
2008-03-04 03:27:20 +00:00
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
|
echo c >d &&
|
|
|
|
|
git update-index --add d &&
|
2015-12-23 13:45:51 +00:00
|
|
|
tree=$(git write-tree) &&
|
|
|
|
|
commit=$(git commit-tree $tree </dev/null) &&
|
2008-03-04 03:27:20 +00:00
|
|
|
echo "object $commit" >sig &&
|
|
|
|
|
echo "type commit" >>sig &&
|
|
|
|
|
echo "tag mytag" >>sig &&
|
|
|
|
|
echo "tagger $(git var GIT_COMMITTER_IDENT)" >>sig &&
|
|
|
|
|
echo >>sig &&
|
|
|
|
|
echo "our test tag" >>sig &&
|
2015-12-23 13:45:51 +00:00
|
|
|
tag=$(git mktag <sig) &&
|
2008-03-04 03:27:20 +00:00
|
|
|
rm d sig &&
|
|
|
|
|
git update-ref refs/tags/mytag $tag && {
|
|
|
|
|
echo $tree &&
|
|
|
|
|
echo $commit &&
|
|
|
|
|
git ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\) .*/\\1/"
|
|
|
|
|
} >obj-list
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'pack without --include-tag' '
|
2016-09-05 21:52:22 +00:00
|
|
|
packname=$(git pack-objects \
|
2008-03-04 03:27:20 +00:00
|
|
|
--window=0 \
|
2016-09-05 21:52:22 +00:00
|
|
|
test-no-include <obj-list)
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unpack objects' '
|
2016-09-05 21:52:10 +00:00
|
|
|
rm -rf clone.git &&
|
2016-09-05 21:52:17 +00:00
|
|
|
git init clone.git &&
|
2016-09-05 21:52:22 +00:00
|
|
|
git -C clone.git unpack-objects <test-no-include-${packname}.pack
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check unpacked result (have commit, no tag)' '
|
|
|
|
|
git rev-list --objects $commit >list.expect &&
|
2016-09-05 21:52:17 +00:00
|
|
|
test_must_fail git -C clone.git cat-file -e $tag &&
|
|
|
|
|
git -C clone.git rev-list --objects $commit >list.actual &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp list.expect list.actual
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'pack with --include-tag' '
|
2016-09-05 21:52:22 +00:00
|
|
|
packname=$(git pack-objects \
|
2008-03-04 03:27:20 +00:00
|
|
|
--window=0 \
|
|
|
|
|
--include-tag \
|
2016-09-05 21:52:22 +00:00
|
|
|
test-include <obj-list)
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unpack objects' '
|
2016-09-05 21:52:10 +00:00
|
|
|
rm -rf clone.git &&
|
2016-09-05 21:52:17 +00:00
|
|
|
git init clone.git &&
|
2016-09-05 21:52:22 +00:00
|
|
|
git -C clone.git unpack-objects <test-include-${packname}.pack
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check unpacked result (have commit, have tag)' '
|
|
|
|
|
git rev-list --objects mytag >list.expect &&
|
2016-09-05 21:52:17 +00:00
|
|
|
git -C clone.git rev-list --objects $tag >list.actual &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp list.expect list.actual
|
2008-03-04 03:27:20 +00:00
|
|
|
'
|
|
|
|
|
|
pack-objects: walk tag chains for --include-tag
When pack-objects is given --include-tag, it peels each tag
ref down to a non-tag object, and if that non-tag object is
going to be packed, we include the tag, too. But what
happens if we have a chain of tags (e.g., tag "A" points to
tag "B", which points to commit "C")?
We'll peel down to "C" and realize that we want to include
tag "A", but we do not ever consider tag "B", leading to a
broken pack (assuming "B" was not otherwise selected).
Instead, we have to walk the whole chain, adding any tags we
find to the pack.
Interestingly, it doesn't seem possible to trigger this
problem with "git fetch", but you can with "git clone
--single-branch". The reason is that we generate the correct
pack when the client explicitly asks for "A" (because we do
a real reachability analysis there), and "fetch" is more
willing to do so. There are basically two cases:
1. If "C" is already a ref tip, then the client can deduce
that it needs "A" itself (via find_non_local_tags), and
will ask for it explicitly rather than relying on the
include-tag capability. Everything works.
2. If "C" is not already a ref tip, then we hope for
include-tag to send us the correct tag. But it doesn't;
it generates a broken pack. However, the next step is
to do a follow-up run of find_non_local_tags(),
followed by fetch_refs() to backfill any tags we
learned about.
In the normal case, fetch_refs() calls quickfetch(),
which does a connectivity check and sees we have no
new objects to fetch. We just write the refs.
But for the broken-pack case, the connectivity check
fails, and quickfetch will follow-up with the remote,
asking explicitly for each of the ref tips. This picks
up the missing object in a new pack.
For a regular "git clone", we are similarly OK, because we
explicitly request all of the tag refs, and get a correct
pack. But with "--single-branch", we kick in tag
auto-following via "include-tag", but do _not_ do a
follow-up backfill. We just take whatever the server sent us
via include-tag and write out tag refs for any tag objects
we were sent. So prior to c6807a4 (clone: open a shortcut
for connectivity check, 2013-05-26), we actually claimed the
clone was a success, but the result was silently
corrupted! Since c6807a4, index-pack's connectivity
check catches this case, and we correctly complain.
The included test directly checks that pack-objects does not
generate a broken pack, but also confirms that "clone
--single-branch" does not hit the bug.
Note that tag chains introduce another interesting question:
if we are packing the tag "B" but not the commit "C", should
"A" be included?
Both before and after this patch, we do not include "A",
because the initial peel_ref() check only knows about the
bottom-most level, "C". To realize that "B" is involved at
all, we would have to switch to an incremental peel, in
which we examine each tagged object, asking if it is being
packed (and including the outer tag if so).
But that runs contrary to the optimizations in peel_ref(),
which avoid accessing the objects at all, in favor of using
the value we pull from packed-refs. It's OK to walk the
whole chain once we know we're going to include the tag (we
have to access it anyway, so the effort is proportional to
the pack we're generating). But for the initial selection,
we have to look at every ref. If we're only packing a few
objects, we'd still have to parse every single referenced
tag object just to confirm that it isn't part of a tag
chain.
This could be addressed if packed-refs stored the complete
tag chain for each peeled ref (in most cases, this would be
the same cost as now, as each "chain" is only a single
link). But given the size of that project, it's out of scope
for this fix (and probably nobody cares enough anyway, as
it's such an obscure situation). This commit limits itself
to just avoiding the creation of a broken pack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-05 21:52:26 +00:00
|
|
|
# A tag of a tag, where the "inner" tag is not otherwise
|
|
|
|
|
# reachable, and a full peel points to a commit reachable from HEAD.
|
|
|
|
|
test_expect_success 'create hidden inner tag' '
|
|
|
|
|
test_commit commit &&
|
|
|
|
|
git tag -m inner inner HEAD &&
|
|
|
|
|
git tag -m outer outer inner &&
|
|
|
|
|
git tag -d inner
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'pack explicit outer tag' '
|
|
|
|
|
packname=$(
|
|
|
|
|
{
|
|
|
|
|
echo HEAD &&
|
|
|
|
|
echo outer
|
|
|
|
|
} |
|
|
|
|
|
git pack-objects --revs test-hidden-explicit
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unpack objects' '
|
|
|
|
|
rm -rf clone.git &&
|
|
|
|
|
git init clone.git &&
|
|
|
|
|
git -C clone.git unpack-objects <test-hidden-explicit-${packname}.pack
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check unpacked result (have all objects)' '
|
|
|
|
|
git -C clone.git rev-list --objects $(git rev-parse outer HEAD)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'pack implied outer tag' '
|
|
|
|
|
packname=$(
|
|
|
|
|
echo HEAD |
|
|
|
|
|
git pack-objects --revs --include-tag test-hidden-implied
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unpack objects' '
|
|
|
|
|
rm -rf clone.git &&
|
|
|
|
|
git init clone.git &&
|
|
|
|
|
git -C clone.git unpack-objects <test-hidden-implied-${packname}.pack
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check unpacked result (have all objects)' '
|
|
|
|
|
git -C clone.git rev-list --objects $(git rev-parse outer HEAD)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'single-branch clone can transfer tag' '
|
|
|
|
|
rm -rf clone.git &&
|
2020-11-18 23:44:29 +00:00
|
|
|
git clone --no-local --single-branch -b main . clone.git &&
|
pack-objects: walk tag chains for --include-tag
When pack-objects is given --include-tag, it peels each tag
ref down to a non-tag object, and if that non-tag object is
going to be packed, we include the tag, too. But what
happens if we have a chain of tags (e.g., tag "A" points to
tag "B", which points to commit "C")?
We'll peel down to "C" and realize that we want to include
tag "A", but we do not ever consider tag "B", leading to a
broken pack (assuming "B" was not otherwise selected).
Instead, we have to walk the whole chain, adding any tags we
find to the pack.
Interestingly, it doesn't seem possible to trigger this
problem with "git fetch", but you can with "git clone
--single-branch". The reason is that we generate the correct
pack when the client explicitly asks for "A" (because we do
a real reachability analysis there), and "fetch" is more
willing to do so. There are basically two cases:
1. If "C" is already a ref tip, then the client can deduce
that it needs "A" itself (via find_non_local_tags), and
will ask for it explicitly rather than relying on the
include-tag capability. Everything works.
2. If "C" is not already a ref tip, then we hope for
include-tag to send us the correct tag. But it doesn't;
it generates a broken pack. However, the next step is
to do a follow-up run of find_non_local_tags(),
followed by fetch_refs() to backfill any tags we
learned about.
In the normal case, fetch_refs() calls quickfetch(),
which does a connectivity check and sees we have no
new objects to fetch. We just write the refs.
But for the broken-pack case, the connectivity check
fails, and quickfetch will follow-up with the remote,
asking explicitly for each of the ref tips. This picks
up the missing object in a new pack.
For a regular "git clone", we are similarly OK, because we
explicitly request all of the tag refs, and get a correct
pack. But with "--single-branch", we kick in tag
auto-following via "include-tag", but do _not_ do a
follow-up backfill. We just take whatever the server sent us
via include-tag and write out tag refs for any tag objects
we were sent. So prior to c6807a4 (clone: open a shortcut
for connectivity check, 2013-05-26), we actually claimed the
clone was a success, but the result was silently
corrupted! Since c6807a4, index-pack's connectivity
check catches this case, and we correctly complain.
The included test directly checks that pack-objects does not
generate a broken pack, but also confirms that "clone
--single-branch" does not hit the bug.
Note that tag chains introduce another interesting question:
if we are packing the tag "B" but not the commit "C", should
"A" be included?
Both before and after this patch, we do not include "A",
because the initial peel_ref() check only knows about the
bottom-most level, "C". To realize that "B" is involved at
all, we would have to switch to an incremental peel, in
which we examine each tagged object, asking if it is being
packed (and including the outer tag if so).
But that runs contrary to the optimizations in peel_ref(),
which avoid accessing the objects at all, in favor of using
the value we pull from packed-refs. It's OK to walk the
whole chain once we know we're going to include the tag (we
have to access it anyway, so the effort is proportional to
the pack we're generating). But for the initial selection,
we have to look at every ref. If we're only packing a few
objects, we'd still have to parse every single referenced
tag object just to confirm that it isn't part of a tag
chain.
This could be addressed if packed-refs stored the complete
tag chain for each peeled ref (in most cases, this would be
the same cost as now, as each "chain" is only a single
link). But given the size of that project, it's out of scope
for this fix (and probably nobody cares enough anyway, as
it's such an obscure situation). This commit limits itself
to just avoiding the creation of a broken pack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-05 21:52:26 +00:00
|
|
|
git -C clone.git fsck
|
|
|
|
|
'
|
|
|
|
|
|
2008-03-04 03:27:20 +00:00
|
|
|
test_done
|