2007-12-02 14:14:13 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2007 Johannes E. Schindelin
|
|
|
|
#
|
|
|
|
|
2008-09-09 21:25:25 +00:00
|
|
|
test_description='git fast-export'
|
2020-11-18 23:44:42 +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
|
|
|
|
|
2007-12-02 14:14:13 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
2009-03-25 23:53:23 +00:00
|
|
|
echo break it > file0 &&
|
|
|
|
git add file0 &&
|
|
|
|
test_tick &&
|
2007-12-02 14:14:13 +00:00
|
|
|
echo Wohlauf > file &&
|
|
|
|
git add file &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m initial &&
|
|
|
|
echo die Luft > file &&
|
|
|
|
echo geht frisch > file2 &&
|
|
|
|
git add file file2 &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m second &&
|
|
|
|
echo und > file2 &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m third file2 &&
|
|
|
|
test_tick &&
|
|
|
|
git tag rein &&
|
|
|
|
git checkout -b wer HEAD^ &&
|
2010-10-31 01:46:54 +00:00
|
|
|
echo lange > file2 &&
|
2007-12-02 14:14:13 +00:00
|
|
|
test_tick &&
|
|
|
|
git commit -m sitzt file2 &&
|
|
|
|
test_tick &&
|
|
|
|
git tag -a -m valentin muss &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git merge -s ours main
|
2007-12-02 14:14:13 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fast-export | fast-import' '
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
MAIN=$(git rev-parse --verify main) &&
|
2007-12-02 14:14:13 +00:00
|
|
|
REIN=$(git rev-parse --verify rein) &&
|
|
|
|
WER=$(git rev-parse --verify wer) &&
|
|
|
|
MUSS=$(git rev-parse --verify muss) &&
|
|
|
|
mkdir new &&
|
|
|
|
git --git-dir=new/.git init &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --all >actual &&
|
2007-12-02 14:14:13 +00:00
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-11-18 23:44:42 +00:00
|
|
|
test $MAIN = $(git rev-parse --verify refs/heads/main) &&
|
2007-12-02 14:14:13 +00:00
|
|
|
test $REIN = $(git rev-parse --verify refs/tags/rein) &&
|
|
|
|
test $WER = $(git rev-parse --verify refs/heads/wer) &&
|
2018-03-27 17:31:37 +00:00
|
|
|
test $MUSS = $(git rev-parse --verify refs/tags/muss)) <actual
|
2007-12-02 14:14:13 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2019-09-25 01:39:58 +00:00
|
|
|
test_expect_success 'fast-export ^muss^{commit} muss' '
|
|
|
|
git fast-export --tag-of-filtered-object=rewrite ^muss^{commit} muss >actual &&
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
tag muss
|
|
|
|
from $(git rev-parse --verify muss^{commit})
|
|
|
|
$(git cat-file tag muss | grep tagger)
|
|
|
|
data 9
|
|
|
|
valentin
|
|
|
|
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2019-10-03 20:27:07 +00:00
|
|
|
test_expect_success 'fast-export --mark-tags ^muss^{commit} muss' '
|
|
|
|
git fast-export --mark-tags --tag-of-filtered-object=rewrite ^muss^{commit} muss >actual &&
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
tag muss
|
|
|
|
mark :1
|
|
|
|
from $(git rev-parse --verify muss^{commit})
|
|
|
|
$(git cat-file tag muss | grep tagger)
|
|
|
|
data 9
|
|
|
|
valentin
|
|
|
|
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
test_expect_success 'fast-export main~2..main' '
|
2007-12-02 14:14:13 +00:00
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export main~2..main >actual &&
|
|
|
|
sed "s/main/partial/" actual |
|
2007-12-02 14:14:13 +00:00
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-11-18 23:44:42 +00:00
|
|
|
test $MAIN != $(git rev-parse --verify refs/heads/partial) &&
|
|
|
|
git diff --exit-code main partial &&
|
|
|
|
git diff --exit-code main^ partial^ &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git rev-parse partial~2)
|
2007-12-02 14:14:13 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
test_expect_success 'fast-export --reference-excluded-parents main~2..main' '
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 07:59:54 +00:00
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export --reference-excluded-parents main~2..main >actual &&
|
|
|
|
grep commit.refs/heads/main actual >commit-count &&
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 07:59:54 +00:00
|
|
|
test_line_count = 2 commit-count &&
|
2020-11-18 23:44:42 +00:00
|
|
|
sed "s/main/rewrite/" actual |
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 07:59:54 +00:00
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-11-18 23:44:42 +00:00
|
|
|
test $MAIN = $(git rev-parse --verify refs/heads/rewrite))
|
fast-export: add --reference-excluded-parents option
git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
git filter-branch $OPTIONS HEAD~8..HEAD
If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit. There
are two alternatives:
1) Don't use the negative revision specification, and when you're
filtering the output to make modifications to the last 8 commits,
just be careful to not modify any earlier commits somehow.
2) First run 'git fast-export --export-marks=somefile HEAD~8', then
run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.
Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected). Also, both are poor from a performance
perspective.
Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum. Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).
Note from Peff:
I think we might be able to do a little more optimization here. If
we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
unchanged in HEAD, I think we'd still print it (because it would not
be marked SHOWN), but we could omit it (by walking the tree of the
boundary commits and marking them shown). I don't think it's a
blocker for what you're doing here, but just a possible future
optimization.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 07:59:54 +00:00
|
|
|
'
|
|
|
|
|
2018-11-16 07:59:56 +00:00
|
|
|
test_expect_success 'fast-export --show-original-ids' '
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export --show-original-ids main >output &&
|
2018-11-16 07:59:56 +00:00
|
|
|
grep ^original-oid output| sed -e s/^original-oid.// | sort >actual &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git rev-list --objects main muss >objects-and-names &&
|
2018-11-16 07:59:56 +00:00
|
|
|
awk "{print \$1}" objects-and-names | sort >commits-trees-blobs &&
|
|
|
|
comm -23 actual commits-trees-blobs >unfound &&
|
|
|
|
test_must_be_empty unfound
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fast-export --show-original-ids | git fast-import' '
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export --show-original-ids main muss | git fast-import --quiet &&
|
|
|
|
test $MAIN = $(git rev-parse --verify refs/heads/main) &&
|
2018-11-16 07:59:56 +00:00
|
|
|
test $MUSS = $(git rev-parse --verify refs/tags/muss)
|
|
|
|
'
|
|
|
|
|
2019-05-14 04:31:02 +00:00
|
|
|
test_expect_success 'reencoding iso-8859-7' '
|
2007-12-02 14:14:13 +00:00
|
|
|
|
2019-05-14 04:30:58 +00:00
|
|
|
test_when_finished "git reset --hard HEAD~1" &&
|
|
|
|
test_config i18n.commitencoding iso-8859-7 &&
|
2007-12-02 14:14:13 +00:00
|
|
|
test_tick &&
|
|
|
|
echo rosten >file &&
|
2019-05-14 04:30:58 +00:00
|
|
|
git commit -s -F "$TEST_DIRECTORY/t9350/simple-iso-8859-7-commit-message.txt" file &&
|
2019-05-14 04:31:02 +00:00
|
|
|
git fast-export --reencode=yes wer^..wer >iso-8859-7.fi &&
|
2019-05-14 04:30:58 +00:00
|
|
|
sed "s/wer/i18n/" iso-8859-7.fi |
|
2007-12-02 14:14:13 +00:00
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-07-29 23:14:13 +00:00
|
|
|
# The commit object, if not re-encoded, would be 200 bytes plus hash.
|
2019-05-14 04:30:58 +00:00
|
|
|
# Removing the "encoding iso-8859-7\n" header drops 20 bytes.
|
|
|
|
# Re-encoding the Pi character from \xF0 (\360) in iso-8859-7
|
|
|
|
# to \xCF\x80 (\317\200) in UTF-8 adds a byte. Check for
|
|
|
|
# the expected size.
|
2020-07-29 23:14:13 +00:00
|
|
|
test $(($(test_oid hexsz) + 181)) -eq "$(git cat-file -s i18n)" &&
|
2019-05-14 04:30:58 +00:00
|
|
|
# ...and for the expected translation of bytes.
|
2018-03-27 17:31:37 +00:00
|
|
|
git cat-file commit i18n >actual &&
|
2019-05-14 04:30:58 +00:00
|
|
|
grep $(printf "\317\200") actual &&
|
|
|
|
# Also make sure the commit does not have the "encoding" header
|
|
|
|
! grep ^encoding actual)
|
2008-06-11 11:17:04 +00:00
|
|
|
'
|
2019-05-14 04:30:58 +00:00
|
|
|
|
2019-05-14 04:31:02 +00:00
|
|
|
test_expect_success 'aborting on iso-8859-7' '
|
|
|
|
|
|
|
|
test_when_finished "git reset --hard HEAD~1" &&
|
|
|
|
test_config i18n.commitencoding iso-8859-7 &&
|
|
|
|
echo rosten >file &&
|
|
|
|
git commit -s -F "$TEST_DIRECTORY/t9350/simple-iso-8859-7-commit-message.txt" file &&
|
|
|
|
test_must_fail git fast-export --reencode=abort wer^..wer >iso-8859-7.fi
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'preserving iso-8859-7' '
|
|
|
|
|
|
|
|
test_when_finished "git reset --hard HEAD~1" &&
|
|
|
|
test_config i18n.commitencoding iso-8859-7 &&
|
|
|
|
echo rosten >file &&
|
|
|
|
git commit -s -F "$TEST_DIRECTORY/t9350/simple-iso-8859-7-commit-message.txt" file &&
|
|
|
|
git fast-export --reencode=no wer^..wer >iso-8859-7.fi &&
|
|
|
|
sed "s/wer/i18n-no-recoding/" iso-8859-7.fi |
|
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-07-29 23:14:13 +00:00
|
|
|
# The commit object, if not re-encoded, is 200 bytes plus hash.
|
2019-05-14 04:31:02 +00:00
|
|
|
# Removing the "encoding iso-8859-7\n" header would drops 20
|
|
|
|
# bytes. Re-encoding the Pi character from \xF0 (\360) in
|
|
|
|
# iso-8859-7 to \xCF\x80 (\317\200) in UTF-8 adds a byte.
|
|
|
|
# Check for the expected size...
|
2020-07-29 23:14:13 +00:00
|
|
|
test $(($(test_oid hexsz) + 200)) -eq "$(git cat-file -s i18n-no-recoding)" &&
|
2019-05-14 04:31:02 +00:00
|
|
|
# ...as well as the expected byte.
|
|
|
|
git cat-file commit i18n-no-recoding >actual &&
|
|
|
|
grep $(printf "\360") actual &&
|
|
|
|
# Also make sure the commit has the "encoding" header
|
|
|
|
grep ^encoding actual)
|
|
|
|
'
|
|
|
|
|
2019-05-14 04:31:00 +00:00
|
|
|
test_expect_success 'encoding preserved if reencoding fails' '
|
|
|
|
|
|
|
|
test_when_finished "git reset --hard HEAD~1" &&
|
|
|
|
test_config i18n.commitencoding iso-8859-7 &&
|
|
|
|
echo rosten >file &&
|
|
|
|
git commit -s -F "$TEST_DIRECTORY/t9350/broken-iso-8859-7-commit-message.txt" file &&
|
2019-05-14 04:31:02 +00:00
|
|
|
git fast-export --reencode=yes wer^..wer >iso-8859-7.fi &&
|
2019-05-14 04:31:00 +00:00
|
|
|
sed "s/wer/i18n-invalid/" iso-8859-7.fi |
|
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
|
|
|
git cat-file commit i18n-invalid >actual &&
|
|
|
|
# Make sure the commit still has the encoding header
|
|
|
|
grep ^encoding actual &&
|
|
|
|
# Verify that the commit has the expected size; i.e.
|
|
|
|
# that no bytes were re-encoded to a different encoding.
|
2020-07-29 23:14:13 +00:00
|
|
|
test $(($(test_oid hexsz) + 212)) -eq "$(git cat-file -s i18n-invalid)" &&
|
2019-05-14 04:31:00 +00:00
|
|
|
# ...and check for the original special bytes
|
|
|
|
grep $(printf "\360") actual &&
|
|
|
|
grep $(printf "\377") actual)
|
|
|
|
'
|
|
|
|
|
2008-06-11 11:17:04 +00:00
|
|
|
test_expect_success 'import/export-marks' '
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
git checkout -b marks main &&
|
2008-06-11 11:17:04 +00:00
|
|
|
git fast-export --export-marks=tmp-marks HEAD &&
|
|
|
|
test -s tmp-marks &&
|
2012-04-11 11:24:01 +00:00
|
|
|
test_line_count = 3 tmp-marks &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --import-marks=tmp-marks \
|
|
|
|
--export-marks=tmp-marks HEAD >actual &&
|
|
|
|
test $(grep ^commit actual | wc -l) -eq 0 &&
|
2008-06-11 11:17:04 +00:00
|
|
|
echo change > file &&
|
|
|
|
git commit -m "last commit" file &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --import-marks=tmp-marks \
|
|
|
|
--export-marks=tmp-marks HEAD >actual &&
|
|
|
|
test $(grep ^commit\ actual | wc -l) -eq 1 &&
|
2012-04-11 11:24:01 +00:00
|
|
|
test_line_count = 4 tmp-marks
|
2008-06-11 11:17:04 +00:00
|
|
|
|
2007-12-02 14:14:13 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
cat > signed-tag-import << EOF
|
|
|
|
tag sign-your-name
|
|
|
|
from $(git rev-parse HEAD)
|
|
|
|
tagger C O Mitter <committer@example.com> 1112911993 -0700
|
|
|
|
data 210
|
|
|
|
A message for a sign
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
|
|
Version: GnuPG v1.4.5 (GNU/Linux)
|
|
|
|
|
|
|
|
fakedsignaturefakedsignaturefakedsignaturefakedsignaturfakedsign
|
|
|
|
aturefakedsignaturefake=
|
|
|
|
=/59v
|
|
|
|
-----END PGP SIGNATURE-----
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'set up faked signed tag' '
|
|
|
|
|
2024-03-15 19:46:11 +00:00
|
|
|
git fast-import <signed-tag-import
|
2007-12-02 14:14:13 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'signed-tags=abort' '
|
|
|
|
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git fast-export --signed-tags=abort sign-your-name
|
2007-12-02 14:14:13 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2007-12-03 22:44:39 +00:00
|
|
|
test_expect_success 'signed-tags=verbatim' '
|
2007-12-02 14:14:13 +00:00
|
|
|
|
2007-12-03 22:44:39 +00:00
|
|
|
git fast-export --signed-tags=verbatim sign-your-name > output &&
|
2007-12-02 14:14:13 +00:00
|
|
|
grep PGP output
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'signed-tags=strip' '
|
|
|
|
|
|
|
|
git fast-export --signed-tags=strip sign-your-name > output &&
|
|
|
|
! grep PGP output
|
|
|
|
|
|
|
|
'
|
|
|
|
|
2013-04-14 10:57:06 +00:00
|
|
|
test_expect_success 'signed-tags=warn-strip' '
|
|
|
|
git fast-export --signed-tags=warn-strip sign-your-name >output 2>err &&
|
|
|
|
! grep PGP output &&
|
|
|
|
test -s err
|
|
|
|
'
|
|
|
|
|
2008-07-19 12:21:24 +00:00
|
|
|
test_expect_success 'setup submodule' '
|
|
|
|
|
2022-07-29 19:21:53 +00:00
|
|
|
test_config_global protocol.file.allow always &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git checkout -f main &&
|
2008-07-19 12:21:24 +00:00
|
|
|
mkdir sub &&
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
|
|
|
cd sub &&
|
|
|
|
git init &&
|
|
|
|
echo test file > file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m sub_initial
|
|
|
|
) &&
|
2016-01-12 11:49:36 +00:00
|
|
|
git submodule add "$(pwd)/sub" sub &&
|
2008-07-19 12:21:24 +00:00
|
|
|
git commit -m initial &&
|
|
|
|
test_tick &&
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
|
|
|
cd sub &&
|
|
|
|
echo more data >> file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m sub_second
|
|
|
|
) &&
|
2008-07-19 12:21:24 +00:00
|
|
|
git add sub &&
|
|
|
|
git commit -m second
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'submodule fast-export | fast-import' '
|
|
|
|
|
2022-07-29 19:21:53 +00:00
|
|
|
test_config_global protocol.file.allow always &&
|
2020-11-18 23:44:42 +00:00
|
|
|
SUBENT1=$(git ls-tree main^ sub) &&
|
|
|
|
SUBENT2=$(git ls-tree main sub) &&
|
2008-07-19 12:21:24 +00:00
|
|
|
rm -rf new &&
|
|
|
|
mkdir new &&
|
|
|
|
git --git-dir=new/.git init &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --signed-tags=strip --all >actual &&
|
2008-07-19 12:21:24 +00:00
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
2020-11-18 23:44:42 +00:00
|
|
|
test "$SUBENT1" = "$(git ls-tree refs/heads/main^ sub)" &&
|
|
|
|
test "$SUBENT2" = "$(git ls-tree refs/heads/main sub)" &&
|
|
|
|
git checkout main &&
|
2008-07-19 12:21:24 +00:00
|
|
|
git submodule init &&
|
|
|
|
git submodule update &&
|
2018-03-27 17:31:37 +00:00
|
|
|
cmp sub/file ../sub/file) <actual
|
2008-07-19 12:21:24 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2009-02-18 19:17:27 +00:00
|
|
|
GIT_AUTHOR_NAME='A U Thor'; export GIT_AUTHOR_NAME
|
|
|
|
GIT_COMMITTER_NAME='C O Mitter'; export GIT_COMMITTER_NAME
|
2008-07-26 20:52:54 +00:00
|
|
|
|
|
|
|
test_expect_success 'setup copies' '
|
|
|
|
|
|
|
|
git checkout -b copy rein &&
|
|
|
|
git mv file file3 &&
|
|
|
|
git commit -m move1 &&
|
|
|
|
test_tick &&
|
|
|
|
cp file2 file4 &&
|
|
|
|
git add file4 &&
|
|
|
|
git mv file2 file5 &&
|
|
|
|
git commit -m copy1 &&
|
|
|
|
test_tick &&
|
|
|
|
cp file3 file6 &&
|
|
|
|
git add file6 &&
|
|
|
|
git commit -m copy2 &&
|
|
|
|
test_tick &&
|
|
|
|
echo more text >> file6 &&
|
|
|
|
echo even more text >> file6 &&
|
|
|
|
git add file6 &&
|
|
|
|
git commit -m modify &&
|
|
|
|
test_tick &&
|
|
|
|
cp file6 file7 &&
|
|
|
|
echo test >> file7 &&
|
|
|
|
git add file7 &&
|
|
|
|
git commit -m copy_modify
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fast-export -C -C | fast-import' '
|
|
|
|
|
|
|
|
ENTRY=$(git rev-parse --verify copy) &&
|
|
|
|
rm -rf new &&
|
|
|
|
mkdir new &&
|
|
|
|
git --git-dir=new/.git init &&
|
|
|
|
git fast-export -C -C --signed-tags=strip --all > output &&
|
2017-09-20 23:55:02 +00:00
|
|
|
grep "^C file2 file4\$" output &&
|
2008-07-26 20:52:54 +00:00
|
|
|
cat output |
|
|
|
|
(cd new &&
|
|
|
|
git fast-import &&
|
|
|
|
test $ENTRY = $(git rev-parse --verify refs/heads/copy))
|
|
|
|
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
test_expect_success 'fast-export | fast-import when main is tagged' '
|
2008-11-22 18:22:48 +00:00
|
|
|
|
|
|
|
git tag -m msg last &&
|
|
|
|
git fast-export -C -C --signed-tags=strip --all > output &&
|
|
|
|
test $(grep -c "^tag " output) = 3
|
|
|
|
|
|
|
|
'
|
|
|
|
|
2008-12-20 00:00:27 +00:00
|
|
|
cat > tag-content << EOF
|
|
|
|
object $(git rev-parse HEAD)
|
|
|
|
type commit
|
|
|
|
tag rosten
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'cope with tagger-less tags' '
|
|
|
|
|
2023-01-18 20:41:56 +00:00
|
|
|
TAG=$(git hash-object --literally -t tag -w tag-content) &&
|
2008-12-20 00:00:27 +00:00
|
|
|
git update-ref refs/tags/sonnenschein $TAG &&
|
|
|
|
git fast-export -C -C --signed-tags=strip --all > output &&
|
|
|
|
test $(grep -c "^tag " output) = 4 &&
|
|
|
|
! grep "Unspecified Tagger" output &&
|
|
|
|
git fast-export -C -C --signed-tags=strip --all \
|
|
|
|
--fake-missing-tagger > output &&
|
|
|
|
test $(grep -c "^tag " output) = 4 &&
|
|
|
|
grep "Unspecified Tagger" output
|
|
|
|
|
|
|
|
'
|
|
|
|
|
2009-06-26 04:48:32 +00:00
|
|
|
test_expect_success 'setup for limiting exports by PATH' '
|
|
|
|
mkdir limit-by-paths &&
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
|
|
|
cd limit-by-paths &&
|
|
|
|
git init &&
|
|
|
|
echo hi > there &&
|
|
|
|
git add there &&
|
|
|
|
git commit -m "First file" &&
|
|
|
|
echo foo > bar &&
|
|
|
|
git add bar &&
|
|
|
|
git commit -m "Second file" &&
|
|
|
|
git tag -a -m msg mytag &&
|
|
|
|
echo morefoo >> bar &&
|
|
|
|
git add bar &&
|
|
|
|
git commit -m "Change to second file"
|
|
|
|
)
|
2009-06-26 04:48:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
cat > limit-by-paths/expected << EOF
|
|
|
|
blob
|
|
|
|
mark :1
|
|
|
|
data 3
|
|
|
|
hi
|
|
|
|
|
|
|
|
reset refs/tags/mytag
|
|
|
|
commit refs/tags/mytag
|
|
|
|
mark :2
|
|
|
|
author A U Thor <author@example.com> 1112912713 -0700
|
|
|
|
committer C O Mitter <committer@example.com> 1112912713 -0700
|
|
|
|
data 11
|
|
|
|
First file
|
|
|
|
M 100644 :1 there
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'dropping tag of filtered out object' '
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
2009-06-26 04:48:32 +00:00
|
|
|
cd limit-by-paths &&
|
|
|
|
git fast-export --tag-of-filtered-object=drop mytag -- there > output &&
|
2012-11-28 22:11:09 +00:00
|
|
|
test_cmp expected output
|
2010-03-29 00:42:11 +00:00
|
|
|
)
|
2009-06-26 04:48:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
cat >> limit-by-paths/expected << EOF
|
|
|
|
tag mytag
|
|
|
|
from :2
|
|
|
|
tagger C O Mitter <committer@example.com> 1112912713 -0700
|
|
|
|
data 4
|
|
|
|
msg
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'rewriting tag of filtered out object' '
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
2009-06-26 04:48:32 +00:00
|
|
|
cd limit-by-paths &&
|
|
|
|
git fast-export --tag-of-filtered-object=rewrite mytag -- there > output &&
|
2012-11-28 22:11:09 +00:00
|
|
|
test_cmp expected output
|
2010-03-29 00:42:11 +00:00
|
|
|
)
|
2009-06-26 04:48:32 +00:00
|
|
|
'
|
|
|
|
|
2018-11-16 07:59:50 +00:00
|
|
|
test_expect_success 'rewrite tag predating pathspecs to nothing' '
|
|
|
|
test_create_repo rewrite_tag_predating_pathspecs &&
|
|
|
|
(
|
|
|
|
cd rewrite_tag_predating_pathspecs &&
|
|
|
|
|
|
|
|
test_commit initial &&
|
|
|
|
|
|
|
|
git tag -a -m "Some old tag" v0.0.0.0.0.0.1 &&
|
|
|
|
|
|
|
|
test_commit bar &&
|
|
|
|
|
|
|
|
git fast-export --tag-of-filtered-object=rewrite --all -- bar.t >output &&
|
|
|
|
grep from.$ZERO_OID output
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2009-06-26 04:48:32 +00:00
|
|
|
cat > limit-by-paths/expected << EOF
|
|
|
|
blob
|
|
|
|
mark :1
|
|
|
|
data 4
|
|
|
|
foo
|
|
|
|
|
|
|
|
blob
|
|
|
|
mark :2
|
|
|
|
data 3
|
|
|
|
hi
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
reset refs/heads/main
|
|
|
|
commit refs/heads/main
|
2009-06-26 04:48:32 +00:00
|
|
|
mark :3
|
|
|
|
author A U Thor <author@example.com> 1112912713 -0700
|
|
|
|
committer C O Mitter <committer@example.com> 1112912713 -0700
|
|
|
|
data 12
|
|
|
|
Second file
|
|
|
|
M 100644 :1 bar
|
|
|
|
M 100644 :2 there
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_failure 'no exact-ref revisions included' '
|
2010-03-29 00:42:11 +00:00
|
|
|
(
|
|
|
|
cd limit-by-paths &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export main~2..main~1 > output &&
|
2012-11-28 22:11:09 +00:00
|
|
|
test_cmp expected output
|
2010-03-29 00:42:11 +00:00
|
|
|
)
|
2009-06-26 04:48:32 +00:00
|
|
|
'
|
|
|
|
|
2010-07-17 17:00:50 +00:00
|
|
|
test_expect_success 'path limiting with import-marks does not lose unmodified files' '
|
|
|
|
git checkout -b simple marks~2 &&
|
|
|
|
git fast-export --export-marks=marks simple -- file > /dev/null &&
|
|
|
|
echo more content >> file &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -mnext file &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --import-marks=marks simple -- file file0 >actual &&
|
|
|
|
grep file0 actual
|
2010-07-17 17:00:50 +00:00
|
|
|
'
|
|
|
|
|
2022-04-30 14:31:43 +00:00
|
|
|
test_expect_success 'path limiting works' '
|
|
|
|
git fast-export simple -- file >actual &&
|
|
|
|
sed -ne "s/^M .* //p" <actual | sort -u >actual.files &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect actual.files
|
|
|
|
'
|
|
|
|
|
2018-11-16 07:59:52 +00:00
|
|
|
test_expect_success 'avoid corrupt stream with non-existent mark' '
|
|
|
|
test_create_repo avoid_non_existent_mark &&
|
|
|
|
(
|
|
|
|
cd avoid_non_existent_mark &&
|
|
|
|
|
|
|
|
test_commit important-path &&
|
|
|
|
|
|
|
|
test_commit ignored &&
|
|
|
|
|
|
|
|
git branch A &&
|
|
|
|
git branch B &&
|
|
|
|
|
|
|
|
echo foo >>important-path.t &&
|
|
|
|
git add important-path.t &&
|
|
|
|
test_commit more changes &&
|
|
|
|
|
|
|
|
git fast-export --all -- important-path.t | git fast-import --force
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2010-07-17 17:00:51 +00:00
|
|
|
test_expect_success 'full-tree re-shows unmodified files' '
|
|
|
|
git checkout -f simple &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git fast-export --full-tree simple >actual &&
|
|
|
|
test $(grep -c file0 actual) -eq 3
|
2010-07-17 17:00:51 +00:00
|
|
|
'
|
|
|
|
|
2009-03-23 12:53:06 +00:00
|
|
|
test_expect_success 'set-up a few more tags for tag export tests' '
|
2020-11-18 23:44:42 +00:00
|
|
|
git checkout -f main &&
|
2024-03-15 19:46:17 +00:00
|
|
|
HEAD_TREE=$(git show -s --pretty=raw HEAD | sed -n "/tree/s/tree //p") &&
|
2009-03-23 12:53:06 +00:00
|
|
|
git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
|
|
|
|
git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
|
|
|
|
git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
|
|
|
|
git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
|
|
|
|
'
|
|
|
|
|
2009-06-26 04:48:28 +00:00
|
|
|
test_expect_success 'tree_tag' '
|
|
|
|
mkdir result &&
|
|
|
|
(cd result && git init) &&
|
|
|
|
git fast-export tree_tag > fe-stream &&
|
|
|
|
(cd result && git fast-import < ../fe-stream)
|
|
|
|
'
|
|
|
|
|
2009-03-23 12:53:06 +00:00
|
|
|
# NEEDSWORK: not just check return status, but validate the output
|
2019-10-03 20:27:08 +00:00
|
|
|
# Note that these tests DO NOTHING other than print a warning that
|
2019-11-05 17:07:24 +00:00
|
|
|
# they are omitting the one tag we asked them to export (because the
|
2019-10-03 20:27:08 +00:00
|
|
|
# tags resolve to a tree). They exist just to make sure we do not
|
|
|
|
# abort but instead just warn.
|
2009-03-23 12:53:08 +00:00
|
|
|
test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
|
2009-03-23 12:53:09 +00:00
|
|
|
test_expect_success 'tag-obj_tag' 'git fast-export tag-obj_tag'
|
|
|
|
test_expect_success 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
|
2009-03-23 12:53:06 +00:00
|
|
|
|
2019-10-03 20:27:08 +00:00
|
|
|
test_expect_success 'handling tags of blobs' '
|
2020-11-18 23:44:42 +00:00
|
|
|
git tag -a -m "Tag of a blob" blobtag $(git rev-parse main:file) &&
|
2019-10-03 20:27:08 +00:00
|
|
|
git fast-export blobtag >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
blob
|
|
|
|
mark :1
|
|
|
|
data 9
|
|
|
|
die Luft
|
|
|
|
|
|
|
|
tag blobtag
|
|
|
|
from :1
|
|
|
|
tagger $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
|
|
|
|
data 14
|
|
|
|
Tag of a blob
|
|
|
|
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2019-10-03 20:27:09 +00:00
|
|
|
test_expect_success 'handling nested tags' '
|
2019-10-03 20:27:08 +00:00
|
|
|
git tag -a -m "This is a nested tag" nested muss &&
|
|
|
|
git fast-export --mark-tags nested >output &&
|
|
|
|
grep "^from $ZERO_OID$" output &&
|
|
|
|
grep "^tag nested$" output >tag_lines &&
|
|
|
|
test_line_count = 2 tag_lines
|
|
|
|
'
|
|
|
|
|
2013-06-07 20:53:28 +00:00
|
|
|
test_expect_success 'directory becomes symlink' '
|
2010-07-09 13:10:51 +00:00
|
|
|
git init dirtosymlink &&
|
|
|
|
git init result &&
|
|
|
|
(
|
|
|
|
cd dirtosymlink &&
|
|
|
|
mkdir foo &&
|
|
|
|
mkdir bar &&
|
|
|
|
echo hello > foo/world &&
|
|
|
|
echo hello > bar/world &&
|
|
|
|
git add foo/world bar/world &&
|
|
|
|
git commit -q -mone &&
|
|
|
|
git rm -r foo &&
|
2013-06-07 20:53:28 +00:00
|
|
|
test_ln_s_add bar foo &&
|
2010-07-09 13:10:51 +00:00
|
|
|
git commit -q -mtwo
|
|
|
|
) &&
|
|
|
|
(
|
|
|
|
cd dirtosymlink &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export main -- foo |
|
2010-07-09 13:10:51 +00:00
|
|
|
(cd ../result && git fast-import --quiet)
|
|
|
|
) &&
|
2020-11-18 23:44:42 +00:00
|
|
|
(cd result && git show main:foo)
|
2010-07-09 13:10:51 +00:00
|
|
|
'
|
|
|
|
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-05 22:36:22 +00:00
|
|
|
test_expect_success 'fast-export quotes pathnames' '
|
|
|
|
git init crazy-paths &&
|
2019-09-12 12:54:05 +00:00
|
|
|
test_config -C crazy-paths core.protectNTFS false &&
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-05 22:36:22 +00:00
|
|
|
(cd crazy-paths &&
|
2016-01-12 11:49:36 +00:00
|
|
|
blob=$(echo foo | git hash-object -w --stdin) &&
|
2019-09-09 13:43:35 +00:00
|
|
|
git -c core.protectNTFS=false update-index --add \
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-05 22:36:22 +00:00
|
|
|
--cacheinfo 100644 $blob "$(printf "path with\\nnewline")" \
|
|
|
|
--cacheinfo 100644 $blob "path with \"quote\"" \
|
|
|
|
--cacheinfo 100644 $blob "path with \\backslash" \
|
|
|
|
--cacheinfo 100644 $blob "path with space" &&
|
|
|
|
git commit -m addition &&
|
2013-10-29 01:23:03 +00:00
|
|
|
git ls-files -z -s | perl -0pe "s{\\t}{$&subdir/}" >index &&
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-05 22:36:22 +00:00
|
|
|
git read-tree --empty &&
|
|
|
|
git update-index -z --index-info <index &&
|
|
|
|
git commit -m rename &&
|
|
|
|
git read-tree --empty &&
|
|
|
|
git commit -m deletion &&
|
2012-06-27 21:58:01 +00:00
|
|
|
git fast-export -M HEAD >export.out &&
|
fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-05 22:36:22 +00:00
|
|
|
git rev-list HEAD >expect &&
|
|
|
|
git init result &&
|
|
|
|
cd result &&
|
|
|
|
git fast-import <../export.out &&
|
|
|
|
git rev-list HEAD >actual &&
|
|
|
|
test_cmp ../expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2012-11-24 03:17:01 +00:00
|
|
|
test_expect_success 'test bidirectionality' '
|
|
|
|
git init marks-test &&
|
2019-10-03 20:27:06 +00:00
|
|
|
git fast-export --export-marks=marks-cur --import-marks-if-exists=marks-cur --branches | \
|
|
|
|
git --git-dir=marks-test/.git fast-import --export-marks=marks-new --import-marks-if-exists=marks-new &&
|
2012-11-24 03:17:01 +00:00
|
|
|
(cd marks-test &&
|
|
|
|
git reset --hard &&
|
|
|
|
echo Wohlauf > file &&
|
|
|
|
git commit -a -m "back in time") &&
|
2019-10-03 20:27:06 +00:00
|
|
|
git --git-dir=marks-test/.git fast-export --export-marks=marks-new --import-marks-if-exists=marks-new --branches | \
|
|
|
|
git fast-import --export-marks=marks-cur --import-marks-if-exists=marks-cur
|
2012-11-24 03:17:01 +00:00
|
|
|
'
|
|
|
|
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:23:59 +00:00
|
|
|
cat > expected << EOF
|
|
|
|
blob
|
|
|
|
mark :13
|
|
|
|
data 5
|
|
|
|
bump
|
|
|
|
|
2020-11-18 23:44:42 +00:00
|
|
|
commit refs/heads/main
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:23:59 +00:00
|
|
|
mark :14
|
|
|
|
author A U Thor <author@example.com> 1112912773 -0700
|
|
|
|
committer C O Mitter <committer@example.com> 1112912773 -0700
|
|
|
|
data 5
|
|
|
|
bump
|
|
|
|
from :12
|
|
|
|
M 100644 :13 file
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'avoid uninteresting refs' '
|
|
|
|
> tmp-marks &&
|
|
|
|
git fast-export --import-marks=tmp-marks \
|
2020-11-18 23:44:42 +00:00
|
|
|
--export-marks=tmp-marks main > /dev/null &&
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:23:59 +00:00
|
|
|
git tag v1.0 &&
|
|
|
|
git branch uninteresting &&
|
|
|
|
echo bump > file &&
|
|
|
|
git commit -a -m bump &&
|
|
|
|
git fast-export --import-marks=tmp-marks \
|
2020-11-18 23:44:42 +00:00
|
|
|
--export-marks=tmp-marks ^uninteresting ^v1.0 main > actual &&
|
fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:23:59 +00:00
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:24:00 +00:00
|
|
|
cat > expected << EOF
|
2020-11-18 23:44:42 +00:00
|
|
|
reset refs/heads/main
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:24:00 +00:00
|
|
|
from :14
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'refs are updated even if no commits need to be exported' '
|
|
|
|
> tmp-marks &&
|
|
|
|
git fast-export --import-marks=tmp-marks \
|
2020-11-18 23:44:42 +00:00
|
|
|
--export-marks=tmp-marks main > /dev/null &&
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:24:00 +00:00
|
|
|
git fast-export --import-marks=tmp-marks \
|
2020-11-18 23:44:42 +00:00
|
|
|
--export-marks=tmp-marks main > actual &&
|
fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28 22:24:00 +00:00
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2014-04-20 18:59:24 +00:00
|
|
|
test_expect_success 'use refspec' '
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export --refspec refs/heads/main:refs/heads/foobar main >actual2 &&
|
2018-03-27 17:31:37 +00:00
|
|
|
grep "^commit " actual2 | sort | uniq >actual &&
|
2014-04-20 18:59:24 +00:00
|
|
|
echo "commit refs/heads/foobar" > expected &&
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2018-11-16 07:59:53 +00:00
|
|
|
test_expect_success 'delete ref because entire history excluded' '
|
2014-04-20 18:59:28 +00:00
|
|
|
git branch to-delete &&
|
2018-11-16 07:59:53 +00:00
|
|
|
git fast-export to-delete ^to-delete >actual &&
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
reset refs/heads/to-delete
|
2020-07-29 23:14:13 +00:00
|
|
|
from $ZERO_OID
|
2018-11-16 07:59:53 +00:00
|
|
|
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'delete refspec' '
|
|
|
|
git fast-export --refspec :refs/heads/to-delete >actual &&
|
|
|
|
cat >expected <<-EOF &&
|
2014-04-20 18:59:28 +00:00
|
|
|
reset refs/heads/to-delete
|
2020-07-29 23:14:13 +00:00
|
|
|
from $ZERO_OID
|
2014-04-20 18:59:28 +00:00
|
|
|
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2017-09-20 23:55:02 +00:00
|
|
|
test_expect_success 'when using -C, do not declare copy when source of copy is also modified' '
|
|
|
|
test_create_repo src &&
|
|
|
|
echo a_line >src/file.txt &&
|
|
|
|
git -C src add file.txt &&
|
|
|
|
git -C src commit -m 1st_commit &&
|
|
|
|
|
|
|
|
cp src/file.txt src/file2.txt &&
|
|
|
|
echo another_line >>src/file.txt &&
|
|
|
|
git -C src add file.txt file2.txt &&
|
|
|
|
git -C src commit -m 2nd_commit &&
|
|
|
|
|
|
|
|
test_create_repo dst &&
|
2018-03-27 17:31:37 +00:00
|
|
|
git -C src fast-export --all -C >actual &&
|
|
|
|
git -C dst fast-import <actual &&
|
2017-09-20 23:55:02 +00:00
|
|
|
git -C src show >expected &&
|
|
|
|
git -C dst show >actual &&
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2018-04-20 22:12:31 +00:00
|
|
|
test_expect_success 'merge commit gets exported with --import-marks' '
|
|
|
|
test_create_repo merging &&
|
|
|
|
(
|
|
|
|
cd merging &&
|
|
|
|
test_commit initial &&
|
|
|
|
git checkout -b topic &&
|
|
|
|
test_commit on-topic &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git checkout main &&
|
|
|
|
test_commit on-main &&
|
2018-04-20 22:12:31 +00:00
|
|
|
test_tick &&
|
|
|
|
git merge --no-ff -m Yeah topic &&
|
|
|
|
|
|
|
|
echo ":1 $(git rev-parse HEAD^^)" >marks &&
|
2020-11-18 23:44:42 +00:00
|
|
|
git fast-export --import-marks=marks main >out &&
|
2018-04-20 22:12:31 +00:00
|
|
|
grep Yeah out
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
fast-export: fix surprising behavior with --first-parent
The revision traversal machinery typically processes and returns all
children before any parent. fast-export needs to operate in the
reverse fashion, handling parents before any of their children in
order to build up the history starting from the root commit(s). This
would be a clear case where we could just use the revision traversal
machinery's "reverse" option to achieve this desired affect.
However, this wasn't what the code did. It added its own array for
queuing. The obvious hand-rolled solution would be to just push all
the commits into the array and then traverse afterwards, but it didn't
quite do that either. It instead attempted to process anything it
could as soon as it could, and once it could, check whether it could
process anything that had been queued. As far as I can tell, this was
an effort to save a little memory in the case of multiple root commits
since it could process some commits before queueing all of them. This
involved some helper functions named has_unshown_parent() and
handle_tail(). For typical invocations of fast-export, this
alternative essentially amounted to a hand-rolled method of reversing
the commits -- it was a bunch of work to duplicate the revision
traversal machinery's "reverse" option.
This hand-rolled reversing mechanism is actually somewhat difficult to
reason about. It takes some time to figure out how it ensures in
normal cases that it will actually process all traversed commits
(rather than just dropping some and not printing anything for them).
And it turns out there are some cases where the code does drop commits
without handling them, and not even printing an error or warning for
the user. Due to the has_unshown_parent() checks, some commits could
be left in the array at the end of the "while...get_revision()" loop
which would be unprocessed. This could be triggered for example with
git fast-export main -- --first-parent
or non-sensical traversal rules such as
git fast-export main -- --grep=Merge --invert-grep
While most traversals that don't include all parents should likely
trigger errors in fast-export (or at least require being used in
combination with --reference-excluded-parents), the --first-parent
traversal is at least reasonable and it'd be nice if it didn't just drop
commits. It'd also be nice for future readers of the code to have a
simpler "reverse traversal" mechanism. Use the "reverse" option of the
revision traversal machinery to achieve both.
Even for the non-sensical traversal flags like the --grep one above,
this would be an improvement. For example, in that case, the code
previously would have silently truncated history to only those commits
that do not have an ancestor containing "Merge" in their commit message.
After this code change, that case would include all commits without
"Merge" in their commit message -- but any commit that previously had a
"Merge"-mentioning parent would lose that parent
(likely resulting in many new root commits). While the new behavior is
still odd, it is at least understandable given that
--reference-excluded-parents is not the default.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: William Sprent <williams@unity3d.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-16 16:23:09 +00:00
|
|
|
|
|
|
|
test_expect_success 'fast-export --first-parent outputs all revisions output by revision walk' '
|
|
|
|
git init first-parent &&
|
|
|
|
(
|
|
|
|
cd first-parent &&
|
|
|
|
test_commit A &&
|
|
|
|
git checkout -b topic1 &&
|
|
|
|
test_commit B &&
|
|
|
|
git checkout main &&
|
|
|
|
git merge --no-ff topic1 &&
|
|
|
|
|
|
|
|
git checkout -b topic2 &&
|
|
|
|
test_commit C &&
|
|
|
|
git checkout main &&
|
|
|
|
git merge --no-ff topic2 &&
|
|
|
|
|
|
|
|
test_commit D &&
|
|
|
|
|
|
|
|
git fast-export main -- --first-parent >first-parent-export &&
|
|
|
|
git fast-export main -- --first-parent --reverse >first-parent-reverse-export &&
|
|
|
|
test_cmp first-parent-export first-parent-reverse-export &&
|
|
|
|
|
|
|
|
git init import &&
|
|
|
|
git -C import fast-import <first-parent-export &&
|
|
|
|
|
|
|
|
git log --format="%ad %s" --first-parent main >expected &&
|
|
|
|
git -C import log --format="%ad %s" --all >actual &&
|
|
|
|
test_cmp expected actual &&
|
|
|
|
test_line_count = 4 actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
parse-options: decouple "--end-of-options" and "--"
When we added generic end-of-options support in 51b4594b40
(parse-options: allow --end-of-options as a synonym for "--",
2019-08-06), we made them true synonyms. They both stop option parsing,
and they are both returned in the resulting argv if the KEEP_DASHDASH
flag is used.
The hope was that this would work for all callers:
- most generic callers would not pass KEEP_DASHDASH, and so would just
do the right thing (stop parsing there) without needing to know
anything more.
- callers with KEEP_DASHDASH were generally going to rely on
setup_revisions(), which knew to handle --end-of-options specially
But that turned out miss quite a few cases that pass KEEP_DASHDASH but
do their own manual parsing. For example, "git reset", "git checkout",
and so on want pass KEEP_DASHDASH so they can support:
git reset $revs -- $paths
but of course aren't going to actually do a traversal, so they don't
call setup_revisions(). And those cases currently get confused by
--end-of-options being left in place, like:
$ git reset --end-of-options HEAD
fatal: option '--end-of-options' must come before non-option arguments
We could teach each of these callers to handle the leftover option
explicitly. But let's try to be a bit more clever and see if we can
solve it centrally in parse-options.c.
The bogus assumption here is that KEEP_DASHDASH tells us the caller
wants to see --end-of-options in the result. But really, the callers
which need to know that --end-of-options was reached are those that may
potentially parse more options from argv. In other words, those that
pass the KEEP_UNKNOWN_OPT flag.
If such a caller is aware of --end-of-options (e.g., because they call
setup_revisions() with the result), then this will continue to do the
right thing, treating anything after --end-of-options as a non-option.
And if the caller is not aware of --end-of-options, they are better off
keeping it intact, because either:
1. They are just passing the options along to somebody else anyway, in
which case that somebody would need to know about the
--end-of-options marker.
2. They are going to parse the remainder themselves, at which point
choking on --end-of-options is much better than having it silently
removed. The point is to avoid option injection from untrusted
command line arguments, and bailing is better than quietly treating
the untrusted argument as an option.
This fixes bugs with --end-of-options across several commands, but I've
focused on two in particular here:
- t7102 confirms that "git reset --end-of-options --foo" now works.
This checks two things. One, that we no longer barf on
"--end-of-options" itself (which previously we did, even if the rev
was something vanilla like "HEAD" instead of "--foo"). And two, that
we correctly treat "--foo" as a revision rather than an option.
This fix applies to any other cases which pass KEEP_DASHDASH but not
KEEP_UNKNOWN_OPT, like "git checkout", "git check-attr", "git grep",
etc, which would previously choke on "--end-of-options".
- t9350 shows the opposite case: fast-export passed KEEP_UNKNOWN_OPT
but not KEEP_DASHDASH, but then passed the result on to
setup_revisions(). So it never saw --end-of-options, and would
erroneously parse "fast-export --end-of-options --foo" as having a
"--foo" option. This is now fixed.
Note that this does shut the door for callers which want to know if we
hit end-of-options, but don't otherwise need to keep unknown opts. The
obvious thing here is feeding it to the DWIM verify_filename()
machinery. And indeed, this is a problem even for commands which do
understand --end-of-options already. For example, without this patch,
you get:
$ git log --end-of-options --foo
fatal: option '--foo' must come before non-option arguments
because we refuse to accept "--foo" as a filename (because it starts
with a dash) even though we could know that we saw end-of-options. The
verify_filename() function simply doesn't accept this extra information.
So that is the status quo, and this patch doubles down further on that.
Commands like "git reset" have the same problem, but they won't even
know that parse-options saw --end-of-options! So even if we fixed
verify_filename(), they wouldn't have anything to pass to it.
But in practice I don't think this is a big deal. If you are being
careful enough to use --end-of-options, then you should also be using
"--" to disambiguate and avoid the DWIM behavior in the first place. In
other words, doing:
git log --end-of-options --this-is-a-rev -- --this-is-a-path
works correctly, and will continue to do so. And likewise, with this
patch now:
git reset --end-of-options --this-is-a-rev -- --this-is-a-path
will work, as well.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-06 22:21:45 +00:00
|
|
|
test_expect_success 'fast-export handles --end-of-options' '
|
|
|
|
git update-ref refs/heads/nodash HEAD &&
|
|
|
|
git update-ref refs/heads/--dashes HEAD &&
|
|
|
|
git fast-export --end-of-options nodash >expect &&
|
|
|
|
git fast-export --end-of-options --dashes >actual.raw &&
|
|
|
|
# fix up lines which mention the ref for comparison
|
|
|
|
sed s/--dashes/nodash/ <actual.raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2007-12-02 14:14:13 +00:00
|
|
|
test_done
|