git-commit-vandalism/t/t9128-git-svn-cmd-branch.sh

80 lines
2.1 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2008 Deskin Miller
#
test_description='git svn partial-rebuild tests'
checkout: fix "branch info" memory leaks The "checkout" command is one of the main sources of leaks in the test suite, let's fix the common ones by not leaking from the "struct branch_info". Doing this is rather straightforward, albeit verbose, we need to xstrdup() constant strings going into the struct, and free() the ones we clobber as we go along. This also means that we can delete previous partial leak fixes in this area, i.e. the "path_to_free" accounting added by 96ec7b1e708 (Convert resolve_ref+xstrdup to new resolve_refdup function, 2011-12-13). There was some discussion about whether "we should retain the "const char *" here and cast at free() time, or have it be a "char *". Since this is not a public API with any sort of API boundary let's use "char *", as is already being done for the "refname" member of the same struct. The tests to mark as passing were found with: rm .prove; GIT_SKIP_TESTS=t0027 prove -j8 --state=save t[0-9]*.sh :: --immediate # apply & compile this change prove -j8 --state=failed :: --immediate I.e. the ones that were newly passing when the --state=failed command was run. I left out "t3040-subprojects-basic.sh" and "t4131-apply-fake-ancestor.sh" to to optimization-level related differences similar to the ones noted in[1], except that these would be something the current 'linux-leaks' job would run into. 1. https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-16 19:27:38 +01:00
. ./lib-git-svn.sh
test_expect_success 'initialize svnrepo' '
mkdir import &&
(
(cd import &&
mkdir trunk branches tags &&
(cd trunk &&
echo foo > foo
) &&
svn_cmd import -m "import for git-svn" . "$svnrepo" >/dev/null
) &&
rm -rf import &&
svn_cmd co "$svnrepo"/trunk trunk &&
(cd trunk &&
echo bar >> foo &&
svn_cmd ci -m "updated trunk"
) &&
rm -rf trunk
)
'
test_expect_success 'import into git' '
git svn init --stdlayout "$svnrepo" &&
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 checkout remotes/origin/trunk
'
test_expect_success 'git svn branch tests' '
git svn branch a &&
base=$(git rev-parse HEAD:) &&
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
test $base = $(git rev-parse remotes/origin/a:) &&
git svn branch -m "created branch b blah" b &&
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
test $base = $(git rev-parse remotes/origin/b:) &&
test_must_fail git branch -m "no branchname" &&
git svn branch -n c &&
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
test_must_fail git rev-parse remotes/origin/c &&
test_must_fail git svn branch a &&
git svn branch -t tag1 &&
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
test $base = $(git rev-parse remotes/origin/tags/tag1:) &&
git svn branch --tag tag2 &&
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
test $base = $(git rev-parse remotes/origin/tags/tag2:) &&
git svn tag tag3 &&
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
test $base = $(git rev-parse remotes/origin/tags/tag3:) &&
git svn tag -m "created tag4 foo" tag4 &&
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
test $base = $(git rev-parse remotes/origin/tags/tag4:) &&
test_must_fail git svn tag -m "no tagname" &&
git svn tag -n tag5 &&
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
test_must_fail git rev-parse remotes/origin/tags/tag5 &&
test_must_fail git svn tag tag1
'
test_expect_success 'branch uses correct svn-remote' '
(svn_cmd co "$svnrepo" svn &&
cd svn &&
mkdir mirror &&
svn_cmd add mirror &&
svn_cmd copy trunk mirror/ &&
svn_cmd copy tags mirror/ &&
svn_cmd copy branches mirror/ &&
svn_cmd ci -m "made mirror" ) &&
rm -rf svn &&
git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
git svn fetch -R mirror &&
git checkout mirror/trunk &&
base=$(git rev-parse HEAD:) &&
git svn branch -m "branch in mirror" d &&
test $base = $(git rev-parse remotes/mirror/d:) &&
test_must_fail git rev-parse remotes/d
'
test_done