2010-08-15 15:15:55 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git svn fetch deleted tag'
|
|
|
|
|
2020-11-19 00:44:42 +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-08-15 15:15:55 +02:00
|
|
|
. ./lib-git-svn.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup svn repo' '
|
|
|
|
mkdir -p import/trunk/subdir &&
|
|
|
|
mkdir -p import/branches &&
|
|
|
|
mkdir -p import/tags &&
|
|
|
|
echo "base" >import/trunk/subdir/file &&
|
|
|
|
svn_cmd import -m "import for git svn" import "$svnrepo" &&
|
|
|
|
rm -rf import &&
|
|
|
|
|
2010-08-19 21:03:18 +02:00
|
|
|
svn_cmd mkdir -m "create mybranch directory" "$svnrepo/branches/mybranch" &&
|
2010-08-15 15:15:55 +02:00
|
|
|
svn_cmd cp -m "create branch mybranch" "$svnrepo/trunk" "$svnrepo/branches/mybranch/trunk" &&
|
|
|
|
|
|
|
|
svn_cmd co "$svnrepo/trunk" svn_project &&
|
|
|
|
(cd svn_project &&
|
|
|
|
echo "trunk change" >>subdir/file &&
|
|
|
|
svn_cmd ci -m "trunk change" subdir/file &&
|
|
|
|
|
|
|
|
svn_cmd switch "$svnrepo/branches/mybranch/trunk" &&
|
|
|
|
echo "branch change" >>subdir/file &&
|
|
|
|
svn_cmd ci -m "branch change" subdir/file
|
|
|
|
) &&
|
|
|
|
|
|
|
|
svn_cmd cp -m "create mytag attempt 1" -r5 "$svnrepo/trunk/subdir" "$svnrepo/tags/mytag" &&
|
|
|
|
svn_cmd rm -m "delete mytag attempt 1" "$svnrepo/tags/mytag" &&
|
|
|
|
svn_cmd cp -m "create mytag attempt 2" -r5 "$svnrepo/branches/mybranch/trunk/subdir" "$svnrepo/tags/mytag"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fetch deleted tags from same revision with checksum error' '
|
|
|
|
git svn init --stdlayout "$svnrepo" git_project &&
|
|
|
|
cd git_project &&
|
|
|
|
git svn fetch &&
|
|
|
|
|
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given
git-svn by default puts its Subversion-tracking refs directly in
refs/remotes/*. This runs counter to Git's convention of using
refs/remotes/$remote/* for storing remote-tracking branches.
Furthermore, combining git-svn with regular git remotes run the risk of
clobbering refs under refs/remotes (e.g. if you have a git remote
called "tags" with a "v1" branch, it will overlap with the git-svn's
tracking branch for the "v1" tag from Subversion.
Even though the git-svn refs stored in refs/remotes/* are not "proper"
remote-tracking branches (since they are not covered by a proper git
remote's refspec), they clearly represent a similar concept, and would
benefit from following the same convention.
For example, if git-svn tracks Subversion branch "foo" at
refs/remotes/foo, and you create a local branch refs/heads/foo to add
some commits to be pushed back to Subversion (using "git svn dcommit),
then it is clearly unhelpful of Git to throw
warning: refname 'foo' is ambiguous.
every time you checkout, rebase, or otherwise interact with the branch.
The existing workaround for this is to supply the --prefix=quux/ to
git svn init/clone, so that git-svn's tracking branches end up in
refs/remotes/quux/* instead of refs/remotes/*. However, encouraging
users to specify --prefix to work around a design flaw in git-svn is
suboptimal, and not a long term solution to the problem. Instead,
git-svn should default to use a non-empty prefix that saves
unsuspecting users from the inconveniences described above.
This patch will only affect newly created git-svn setups, as the
--prefix option only applies to git svn init (and git svn clone).
Existing git-svn setups will continue with their existing (lack of)
prefix. Also, if anyone somehow prefers git-svn's old layout, they
can recreate that by explicitly passing an empty prefix (--prefix "")
on the git svn init/clone command line.
The patch changes the default value for --prefix from "" to "origin/",
updates the git-svn manual page, and fixes the fallout in the git-svn
testcases.
(Note that this patch might be easier to review using the --word-diff
and --word-diff-regex=. diff options.)
[ew: squashed description of <= 1.9 behavior into manpage]
Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 14:57:07 +02:00
|
|
|
git diff --exit-code origin/mybranch:trunk/subdir/file origin/tags/mytag:file &&
|
2020-11-19 00:44:42 +01:00
|
|
|
git diff --exit-code main:subdir/file origin/tags/mytag^:file
|
2010-08-15 15:15:55 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|