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

79 строки
2.1 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
#
# Copyright (c) 2008 Deskin Miller
#
test_description='git svn partial-rebuild tests'
. ./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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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 16:57:07 +04: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