mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-01 06:47:52 +01:00
Code Activity
git/t/t9118-git-svn-funky-branch-names.sh

87 lines
2.7 KiB
Bash
Raw Normal View History

git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
#!/bin/sh
#
# Copyright (c) 2007 Eric Wong
#
t/t91XX git-svn tests: run "git svn" not "git-svn" This replaces 'git-svn' with 'git svn' in the tests. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-08 12:02:08 +02:00
test_description='git svn funky branch names'
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
. ./lib-git-svn.sh
git-svn: fix handling of even funkier branch names Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: Eric Wong <normalperson@yhbt.net>
2008-09-07 05:18:18 +02:00
# Abo-Uebernahme (Bug #994)
scary_uri='Abo-Uebernahme%20%28Bug%20%23994%29'
scary_ref='Abo-Uebernahme%20(Bug%20#994)'
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
test_expect_success 'setup svnrepo' '
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
mkdir project project/trunk project/branches project/tags &&
echo foo > project/trunk/foo &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd import -m "$test_description" project "$svnrepo/pr ject" &&
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
rm -rf project &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd cp -m "fun" "$svnrepo/pr ject/trunk" \
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
"$svnrepo/pr ject/branches/fun plugin" &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd cp -m "more fun!" "$svnrepo/pr ject/branches/fun plugin" \
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
"$svnrepo/pr ject/branches/more fun plugin!" &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd cp -m "scary" "$svnrepo/pr ject/branches/fun plugin" \
git-svn: fix handling of even funkier branch names Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: Eric Wong <normalperson@yhbt.net>
2008-09-07 05:18:18 +02:00
"$svnrepo/pr ject/branches/$scary_uri" &&
git-svn: mangle refnames forbidden in git git-check-ref-format(1) describes names which cannot be used as refnames for git. Some are legal branchnames in subversion however. Mangle the not yet handled cases. Signed-off-by: Torsten Schmutzler <git-ts@theblacksun.eu> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-05-06 22:20:43 +02:00
svn_cmd cp -m "leading dot" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/.leading_dot" &&
svn_cmd cp -m "trailing dot" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/trailing_dot." &&
svn_cmd cp -m "trailing .lock" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/trailing_dotlock.lock" &&
svn_cmd cp -m "reflog" "$svnrepo/pr ject/trunk" \
svn test: escape peg revision separator using empty peg rev This test script uses "svn cp" to create a branch with an @-sign in its name: svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog" That sets up for later tests that fetch the branch and check that git svn mangles the refname appropriately. Unfortunately, modern svn versions interpret path arguments with an @-sign as an example of path@revision syntax (which pegs a path to a particular revision) and truncate the path or error out with message "svn: E205000: Syntax error parsing peg revision '{0}reflog'". When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble (see 08fd28bb, 2010-07-08). Newer versions are stricter: $ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}" svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog' The recommended method for escaping a literal @ sign in a path passed to subversion is to add an empty peg revision at the end of the path ("branches/not-a@{0}reflog@"). Do that. Pre-1.6.12 versions of Subversion probably treat the trailing @ as another literal @-sign (svn issue 3651). Luckily ever since v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN versions, 2012-07-28) the test can survive that. Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837 of Subversion trunk (1.8.x). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-09 10:41:45 +02:00
"$svnrepo/pr ject/branches/not-a@{0}reflog@" &&
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
start_httpd
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
'
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
t9118: workaround inconsistency between SVN versions SVN 1.7 will truncate "not-a%40{0}" to just "not-a". Rather than guess what SVN is going to do for each version, make the test use the branch name that was actually created. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-28 11:47:45 +02:00
# SVN 1.7 will truncate "not-a%40{0]" to just "not-a".
# Look at what SVN wound up naming the branch and use that.
# Be sure to escape the @ if it shows up.
non_reflog=`svn_cmd ls "$svnrepo/pr ject/branches" | grep not-a | sed 's/\///' | sed 's/@/%40/'`
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
test_expect_success 'test clone with funky branch names' '
git svn clone -s "$svnrepo/pr ject" project &&
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
(
cd project &&
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 rev-parse "refs/remotes/origin/fun%20plugin" &&
git rev-parse "refs/remotes/origin/more%20fun%20plugin!" &&
git rev-parse "refs/remotes/origin/$scary_ref" &&
git rev-parse "refs/remotes/origin/%2Eleading_dot" &&
git rev-parse "refs/remotes/origin/trailing_dot%2E" &&
git rev-parse "refs/remotes/origin/trailing_dotlock%2Elock" &&
git rev-parse "refs/remotes/origin/$non_reflog"
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
)
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
'
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
test_expect_success 'test dcommit to funky branch' "
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
(
cd project &&
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 reset --hard 'refs/remotes/origin/more%20fun%20plugin!' &&
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
echo hello >> foo &&
git commit -m 'hello' -- foo &&
git svn dcommit
)
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
"
git-svn: fix handling of even funkier branch names Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: Eric Wong <normalperson@yhbt.net>
2008-09-07 05:18:18 +02:00
test_expect_success 'test dcommit to scary branch' '
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
(
cd project &&
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 reset --hard "refs/remotes/origin/$scary_ref" &&
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
echo urls are scary >> foo &&
git commit -m "eep" -- foo &&
git svn dcommit
)
git-svn: fix handling of even funkier branch names Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: Eric Wong <normalperson@yhbt.net>
2008-09-07 05:18:18 +02:00
'
git-svn: mangle refnames forbidden in git git-check-ref-format(1) describes names which cannot be used as refnames for git. Some are legal branchnames in subversion however. Mangle the not yet handled cases. Signed-off-by: Torsten Schmutzler <git-ts@theblacksun.eu> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-05-06 22:20:43 +02:00
test_expect_success 'test dcommit to trailing_dotlock branch' '
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
(
cd project &&
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 reset --hard "refs/remotes/origin/trailing_dotlock%2Elock" &&
t9118 (git-svn): prevent early failure from taking down later tests When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail. So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed. Reported-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-07-08 15:36:02 +02:00
echo who names branches like this anyway? >> foo &&
git commit -m "bar" -- foo &&
git svn dcommit
)
git-svn: mangle refnames forbidden in git git-check-ref-format(1) describes names which cannot be used as refnames for git. Some are legal branchnames in subversion however. Mangle the not yet handled cases. Signed-off-by: Torsten Schmutzler <git-ts@theblacksun.eu> Acked-by: Eric Wong <normalperson@yhbt.net>
2010-05-06 22:20:43 +02:00
'
git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12 08:37:42 +01:00
stop_httpd
test_done
Copy permalink