2007-01-19 01:50:01 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
# Copyright (c) 2006 Eric Wong
|
2008-09-08 10:02:08 +00:00
|
|
|
test_description='git svn metadata migrations from previous versions'
|
2007-01-19 01:50:01 +00:00
|
|
|
. ./lib-git-svn.sh
|
|
|
|
|
|
2008-05-04 05:37:59 +00:00
|
|
|
test_expect_success 'setup old-looking metadata' '
|
|
|
|
|
cp "$GIT_DIR"/config "$GIT_DIR"/config-old-git-svn &&
|
2007-01-25 19:53:13 +00:00
|
|
|
mkdir import &&
|
2010-09-07 01:42:54 +00: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 08:06:16 +00:00
|
|
|
svn_cmd import -m test . "$svnrepo"
|
2010-09-07 01:42:54 +00:00
|
|
|
) &&
|
2008-09-08 10:02:08 +00:00
|
|
|
git svn init "$svnrepo" &&
|
|
|
|
|
git svn fetch &&
|
2009-08-12 03:14:27 +00:00
|
|
|
rm -rf "$GIT_DIR"/svn &&
|
2016-05-13 20:47:14 +00: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 05:37:59 +00:00
|
|
|
'
|
2007-01-19 01:50:01 +00:00
|
|
|
|
2016-05-13 20:47:24 +00:00
|
|
|
test_expect_success 'git-svn-HEAD is a real HEAD' '
|
|
|
|
|
git rev-parse --verify refs/heads/git-svn-HEAD^0
|
|
|
|
|
'
|
2007-01-19 01:50:01 +00:00
|
|
|
|
2018-01-03 16:54:50 +00:00
|
|
|
svnrepo_escaped=$(echo $svnrepo | sed 's/ /%20/g')
|
2012-07-28 09:47:47 +00:00
|
|
|
|
2008-09-08 10:02:08 +00:00
|
|
|
test_expect_success 'initialize old-style (v0) git svn layout' '
|
2008-05-04 05:37:59 +00: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 10:02:08 +00:00
|
|
|
git svn migrate &&
|
2012-07-28 09:47:46 +00:00
|
|
|
! test -d "$GIT_DIR"/git-svn &&
|
2016-05-13 20:47:14 +00:00
|
|
|
git rev-parse --verify refs/remotes/git-svn^0 &&
|
2007-07-03 05:52:14 +00:00
|
|
|
git rev-parse --verify refs/remotes/svn^0 &&
|
2012-07-28 09:47:47 +00:00
|
|
|
test "$(git config --get svn-remote.svn.url)" = "$svnrepo_escaped" &&
|
2016-01-12 10:45:13 +00:00
|
|
|
test $(git config --get svn-remote.svn.fetch) = \
|
2016-05-13 20:47:14 +00:00
|
|
|
":refs/remotes/git-svn"
|
2008-05-04 05:37:59 +00:00
|
|
|
'
|
2007-01-19 01:50:01 +00:00
|
|
|
|
2008-05-04 05:37:59 +00:00
|
|
|
test_expect_success 'initialize a multi-repository repo' '
|
2008-09-08 10:02:08 +00:00
|
|
|
git svn init "$svnrepo" -T trunk -t tags -b branches &&
|
2007-07-03 05:52:14 +00: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 12:57:07 +00:00
|
|
|
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
|
2016-01-12 10:45:13 +00: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-03 21:29:17 +00: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 12:57:07 +00:00
|
|
|
"^branches/\*:refs/remotes/origin/\*$" &&
|
2007-02-03 21:29:17 +00: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 12:57:07 +00: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" &&
|
2016-05-13 20:47:21 +00:00
|
|
|
for i in tags/0.1 tags/0.2 tags/0.3
|
|
|
|
|
do
|
2007-07-03 05:52:14 +00:00
|
|
|
git config --add svn-remote.svn.fetch \
|
2016-05-13 20:47:21 +00:00
|
|
|
$i:refs/remotes/origin/$i || return 1
|
|
|
|
|
done &&
|
2009-08-04 01:40:37 +00: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 12:57:07 +00: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 &&
|
2016-05-13 20:47:14 +00:00
|
|
|
grep "^:refs/remotes/git-svn" fetch.out
|
2008-05-04 05:37:59 +00:00
|
|
|
'
|
2007-01-19 01:50:01 +00:00
|
|
|
|
2007-01-21 12:27:09 +00:00
|
|
|
# refs should all be different, but the trees should all be the same:
|
2016-05-13 20:47:21 +00:00
|
|
|
test_expect_success 'multi-fetch works on partial urls + paths' '
|
|
|
|
|
refs="trunk a b tags/0.1 tags/0.2 tags/0.3" &&
|
2008-09-08 10:02:08 +00:00
|
|
|
git svn multi-fetch &&
|
2016-05-13 20:47:21 +00:00
|
|
|
for i in $refs
|
|
|
|
|
do
|
|
|
|
|
git rev-parse --verify refs/remotes/origin/$i^0 || return 1;
|
|
|
|
|
done >refs.out &&
|
|
|
|
|
test -z "$(sort <refs.out | uniq -d)" &&
|
|
|
|
|
for i in $refs
|
|
|
|
|
do
|
|
|
|
|
for j in $refs
|
|
|
|
|
do
|
|
|
|
|
git diff --exit-code refs/remotes/origin/$i \
|
|
|
|
|
refs/remotes/origin/$j ||
|
|
|
|
|
return 1
|
|
|
|
|
done
|
|
|
|
|
done
|
|
|
|
|
'
|
2007-01-19 01:50:01 +00:00
|
|
|
|
2008-05-04 05:37:59 +00:00
|
|
|
test_expect_success 'migrate --minimize on old inited layout' '
|
2007-02-14 01:38:58 +00:00
|
|
|
git config --unset-all svn-remote.svn.fetch &&
|
|
|
|
|
git config --unset-all svn-remote.svn.url &&
|
2008-05-04 05:37:59 +00:00
|
|
|
rm -rf "$GIT_DIR"/svn &&
|
2016-05-13 20:47:21 +00:00
|
|
|
for i in $(cat fetch.out)
|
|
|
|
|
do
|
t9107: use shell parameter expansion to avoid breaking &&-chain
This test intentionally breaks the &&-chain when using `expr` to parse
"[<path>]:<ref>" since the pattern matching operation will return 1
(failure) when <path> is empty even though an empty <path> is legitimate
in this test and should not cause the test to fail. However, it is
possible to parse the input without breaking the &&-chain by using shell
parameter expansion (i.e. `${i%%...}`). Other ways to avoid the problem
would be `{ expr $i : ... ||:; }` or test_might_fail(), however,
parameter expansion seems simplest.
IMPLEMENTATION NOTE
The rewritten `if` expression:
if test "$ref" = "${ref#refs/remotes/}"`; then continue; fi
is perhaps a bit subtle. At first glance, it looks like it will
`continue` the loop if $ref starts with "refs/remotes/", but in fact
it's the opposite: the loop will `continue` if $ref does not start with
"refs/remotes/".
In the original, `expr` would only match if the ref started with
"refs/remotes/", and $ref would end up empty if it didn't, so `test -z`
would `continue` the loop if the ref did not start with "refs/remotes/".
With parameter expansion, ${ref#refs/remotes/} attempts to strip
"refs/remotes/" from $ref. If it fails, meaning that $ref does not start
with "refs/remotes/", then the expansion will just be $ref unchanged,
and it will `continue` the loop. On the other hand, if stripping
succeeds, meaning that $ref begins with "refs/remotes/", then the
expansion will be the value of $ref with "refs/remotes/" removed, hence
`continue` will not be taken.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:03 +00:00
|
|
|
path=${i%%:*} &&
|
|
|
|
|
ref=${i#*:} &&
|
|
|
|
|
if test "$ref" = "${ref#refs/remotes/}"; then continue; fi &&
|
|
|
|
|
if test -n "$path"; then path="/$path"; fi &&
|
2016-05-13 20:47:21 +00:00
|
|
|
mkdir -p "$GIT_DIR"/svn/$ref/info/ &&
|
|
|
|
|
echo "$svnrepo"$path >"$GIT_DIR"/svn/$ref/info/url ||
|
|
|
|
|
return 1
|
2007-01-21 12:27:09 +00:00
|
|
|
done &&
|
2008-09-08 10:02:08 +00:00
|
|
|
git svn migrate --minimize &&
|
2016-01-12 10:45:13 +00:00
|
|
|
test -z "$(git config -l | grep "^svn-remote\.git-svn\.")" &&
|
2007-07-03 05:52:14 +00: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 12:57:07 +00: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 &&
|
2016-05-13 20:47:14 +00:00
|
|
|
grep "^:refs/remotes/git-svn" fetch.out
|
2008-05-04 05:37:59 +00:00
|
|
|
'
|
2007-01-21 12:27:09 +00:00
|
|
|
|
2008-05-04 05:37:59 +00:00
|
|
|
test_expect_success ".rev_db auto-converted to .rev_map.UUID" '
|
2008-09-08 10:02:08 +00: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 12:57:07 +00: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 05:37:59 +00: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 10:02:08 +00: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 12:57:07 +00: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 05:37:59 +00:00
|
|
|
test -f "$expect"
|
|
|
|
|
'
|
2007-02-12 21:25:25 +00:00
|
|
|
|
2007-01-19 01:50:01 +00:00
|
|
|
test_done
|
