2007-01-19 09:50:01 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
# Copyright (c) 2006 Eric Wong
|
2008-09-08 18:02:08 +08:00
|
|
|
test_description='git svn metadata migrations from previous versions'
|
2007-01-19 09:50:01 +08:00
|
|
|
. ./lib-git-svn.sh
|
|
|
|
|
|
2008-05-04 13:37:59 +08:00
|
|
|
test_expect_success 'setup old-looking metadata' '
|
|
|
|
|
cp "$GIT_DIR"/config "$GIT_DIR"/config-old-git-svn &&
|
2007-01-26 03:53:13 +08:00
|
|
|
mkdir import &&
|
2010-09-07 09:42:54 +08:00
|
|
|
(
|
|
|
|
|
cd import &&
|
|
|
|
|
for i in trunk branches/a branches/b tags/0.1 tags/0.2 tags/0.3
|
|
|
|
|
do
|
|
|
|
|
mkdir -p $i &&
|
|
|
|
|
echo hello >>$i/README ||
|
|
|
|
|
exit 1
|
|
|
|
|
done &&
|
2009-05-08 16:06:16 +08:00
|
|
|
svn_cmd import -m test . "$svnrepo"
|
2010-09-07 09:42:54 +08:00
|
|
|
) &&
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn init "$svnrepo" &&
|
|
|
|
|
git svn fetch &&
|
2009-08-12 11:14:27 +08:00
|
|
|
rm -rf "$GIT_DIR"/svn &&
|
2008-09-08 18:02:05 +08:00
|
|
|
git update-ref refs/heads/git-svn-HEAD refs/${remotes_git_svn} &&
|
|
|
|
|
git update-ref refs/heads/svn-HEAD refs/${remotes_git_svn} &&
|
|
|
|
|
git update-ref -d refs/${remotes_git_svn} refs/${remotes_git_svn}
|
2008-05-04 13:37:59 +08:00
|
|
|
'
|
2007-01-19 09:50:01 +08:00
|
|
|
|
2016-01-12 18:45:13 +08:00
|
|
|
head=$(git rev-parse --verify refs/heads/git-svn-HEAD^0)
|
2007-01-19 09:50:01 +08:00
|
|
|
test_expect_success 'git-svn-HEAD is a real HEAD' "test -n '$head'"
|
|
|
|
|
|
2016-01-12 18:45:13 +08:00
|
|
|
svnrepo_escaped=$(echo $svnrepo | sed 's/ /%20/')
|
2012-07-28 17:47:47 +08:00
|
|
|
|
2008-09-08 18:02:08 +08:00
|
|
|
test_expect_success 'initialize old-style (v0) git svn layout' '
|
2008-05-04 13:37:59 +08:00
|
|
|
mkdir -p "$GIT_DIR"/git-svn/info "$GIT_DIR"/svn/info &&
|
|
|
|
|
echo "$svnrepo" > "$GIT_DIR"/git-svn/info/url &&
|
|
|
|
|
echo "$svnrepo" > "$GIT_DIR"/svn/info/url &&
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn migrate &&
|
2012-07-28 17:47:46 +08:00
|
|
|
! test -d "$GIT_DIR"/git-svn &&
|
2008-09-08 18:02:05 +08:00
|
|
|
git rev-parse --verify refs/${remotes_git_svn}^0 &&
|
2007-07-03 13:52:14 +08:00
|
|
|
git rev-parse --verify refs/remotes/svn^0 &&
|
2012-07-28 17:47:47 +08:00
|
|
|
test "$(git config --get svn-remote.svn.url)" = "$svnrepo_escaped" &&
|
2016-01-12 18:45:13 +08:00
|
|
|
test $(git config --get svn-remote.svn.fetch) = \
|
2008-09-08 18:02:05 +08:00
|
|
|
":refs/${remotes_git_svn}"
|
2008-05-04 13:37:59 +08:00
|
|
|
'
|
2007-01-19 09:50:01 +08:00
|
|
|
|
2008-05-04 13:37:59 +08:00
|
|
|
test_expect_success 'initialize a multi-repository repo' '
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn init "$svnrepo" -T trunk -t tags -b branches &&
|
2007-07-03 13:52:14 +08:00
|
|
|
git config --get-all svn-remote.svn.fetch > fetch.out &&
|
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 20:57:07 +08:00
|
|
|
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
|
2016-01-12 18:45:13 +08:00
|
|
|
test -n "$(git config --get svn-remote.svn.branches \
|
|
|
|
|
"^branches/\*:refs/remotes/origin/\*$")" &&
|
|
|
|
|
test -n "$(git config --get svn-remote.svn.tags \
|
|
|
|
|
"^tags/\*:refs/remotes/origin/tags/\*$")" &&
|
2007-02-04 05:29:17 +08:00
|
|
|
git config --unset svn-remote.svn.branches \
|
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 20:57:07 +08:00
|
|
|
"^branches/\*:refs/remotes/origin/\*$" &&
|
2007-02-04 05:29:17 +08:00
|
|
|
git config --unset svn-remote.svn.tags \
|
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 20:57:07 +08:00
|
|
|
"^tags/\*:refs/remotes/origin/tags/\*$" &&
|
|
|
|
|
git config --add svn-remote.svn.fetch "branches/a:refs/remotes/origin/a" &&
|
|
|
|
|
git config --add svn-remote.svn.fetch "branches/b:refs/remotes/origin/b" &&
|
2007-02-04 05:29:17 +08:00
|
|
|
for i in tags/0.1 tags/0.2 tags/0.3; do
|
2007-07-03 13:52:14 +08:00
|
|
|
git config --add svn-remote.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 20:57:07 +08:00
|
|
|
$i:refs/remotes/origin/$i || exit 1; done &&
|
2009-08-04 09:40:37 +08:00
|
|
|
git config --get-all svn-remote.svn.fetch > fetch.out &&
|
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 20:57:07 +08:00
|
|
|
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
|
|
|
|
|
grep "^branches/a:refs/remotes/origin/a$" fetch.out &&
|
|
|
|
|
grep "^branches/b:refs/remotes/origin/b$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.1:refs/remotes/origin/tags/0\.1$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.2:refs/remotes/origin/tags/0\.2$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.3:refs/remotes/origin/tags/0\.3$" fetch.out &&
|
2009-08-04 09:40:37 +08:00
|
|
|
grep "^:refs/${remotes_git_svn}" fetch.out
|
2008-05-04 13:37:59 +08:00
|
|
|
'
|
2007-01-19 09:50:01 +08:00
|
|
|
|
2007-01-21 20:27:09 +08:00
|
|
|
# refs should all be different, but the trees should all be the same:
|
2007-01-19 09:50:01 +08:00
|
|
|
test_expect_success 'multi-fetch works on partial urls + paths' "
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn multi-fetch &&
|
2007-01-19 09:50:01 +08:00
|
|
|
for i in trunk a b tags/0.1 tags/0.2 tags/0.3; do
|
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 20:57:07 +08:00
|
|
|
git rev-parse --verify refs/remotes/origin/\$i^0 >> refs.out || exit 1;
|
2007-01-19 09:50:01 +08:00
|
|
|
done &&
|
2016-01-12 18:45:13 +08:00
|
|
|
test -z \"\$(sort < refs.out | uniq -d)\" &&
|
2007-01-19 09:50:01 +08:00
|
|
|
for i in trunk a b tags/0.1 tags/0.2 tags/0.3; do
|
|
|
|
|
for j in trunk a b tags/0.1 tags/0.2 tags/0.3; do
|
|
|
|
|
if test \$j != \$i; then continue; fi
|
2016-01-12 18:45:13 +08:00
|
|
|
test -z \"\$(git diff refs/remotes/origin/\$i \
|
|
|
|
|
refs/remotes/origin/\$j)\" ||exit 1; done; done
|
2007-01-19 09:50:01 +08:00
|
|
|
"
|
|
|
|
|
|
2008-05-04 13:37:59 +08:00
|
|
|
test_expect_success 'migrate --minimize on old inited layout' '
|
2007-02-14 09:38:58 +08:00
|
|
|
git config --unset-all svn-remote.svn.fetch &&
|
|
|
|
|
git config --unset-all svn-remote.svn.url &&
|
2008-05-04 13:37:59 +08:00
|
|
|
rm -rf "$GIT_DIR"/svn &&
|
2016-01-12 18:45:13 +08:00
|
|
|
for i in $(cat fetch.out); do
|
|
|
|
|
path=$(expr $i : "\([^:]*\):.*$")
|
|
|
|
|
ref=$(expr $i : "[^:]*:\(refs/remotes/.*\)$")
|
2008-05-04 13:37:59 +08:00
|
|
|
if test -z "$ref"; then continue; fi
|
|
|
|
|
if test -n "$path"; then path="/$path"; fi
|
|
|
|
|
( mkdir -p "$GIT_DIR"/svn/$ref/info/ &&
|
|
|
|
|
echo "$svnrepo"$path > "$GIT_DIR"/svn/$ref/info/url ) || exit 1;
|
2007-01-21 20:27:09 +08:00
|
|
|
done &&
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn migrate --minimize &&
|
2016-01-12 18:45:13 +08:00
|
|
|
test -z "$(git config -l | grep "^svn-remote\.git-svn\.")" &&
|
2007-07-03 13:52:14 +08:00
|
|
|
git config --get-all svn-remote.svn.fetch > fetch.out &&
|
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 20:57:07 +08:00
|
|
|
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
|
|
|
|
|
grep "^branches/a:refs/remotes/origin/a$" fetch.out &&
|
|
|
|
|
grep "^branches/b:refs/remotes/origin/b$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.1:refs/remotes/origin/tags/0\.1$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.2:refs/remotes/origin/tags/0\.2$" fetch.out &&
|
|
|
|
|
grep "^tags/0\.3:refs/remotes/origin/tags/0\.3$" fetch.out &&
|
2008-09-08 18:02:05 +08:00
|
|
|
grep "^:refs/${remotes_git_svn}" fetch.out
|
2008-05-04 13:37:59 +08:00
|
|
|
'
|
2007-01-21 20:27:09 +08:00
|
|
|
|
2008-05-04 13:37:59 +08:00
|
|
|
test_expect_success ".rev_db auto-converted to .rev_map.UUID" '
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn fetch -i trunk &&
|
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 20:57:07 +08:00
|
|
|
test -z "$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db.* 2>/dev/null)" &&
|
|
|
|
|
expect="$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_map.*)" &&
|
2008-05-04 13:37:59 +08:00
|
|
|
test -n "$expect" &&
|
|
|
|
|
rev_db="$(echo $expect | sed -e "s,_map,_db,")" &&
|
|
|
|
|
convert_to_rev_db "$expect" "$rev_db" &&
|
|
|
|
|
rm -f "$expect" &&
|
|
|
|
|
test -f "$rev_db" &&
|
2008-09-08 18:02:08 +08:00
|
|
|
git svn fetch -i trunk &&
|
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 20:57:07 +08:00
|
|
|
test -z "$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db.* 2>/dev/null)" &&
|
|
|
|
|
test ! -e "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db &&
|
2008-05-04 13:37:59 +08:00
|
|
|
test -f "$expect"
|
|
|
|
|
'
|
2007-02-13 05:25:25 +08:00
|
|
|
|
2007-01-19 09:50:01 +08:00
|
|
|
test_done
|
