All of these cases are moderate since they would most probably not
lead to missed failing tests; either they would fail otherwise, or
fail a rm in test_when_finished only.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
When svn.pushmergeinfo is set, the target branch is included in the
mergeinfo if it was previously merged into one of the source branches.
SVN does not do this.
Remove merge target branch path from resulting mergeinfo when
svn.pushmergeinfo is set to better match the behavior of SVN. Update the
svn-mergeinfo-push test.
[ew: 80 columns]
Signed-off-by: Michael Contreras <michael@inetric.com>
Reported-by: Avishay Lavie <avishay.lavie@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
1e5814f created t9160-git-svn-mergeinfo-push.sh on 11/9/7
40a1530 created t9160-git-svn-preserve-empty-dirs.sh on 11/7/20
The former test script is renumbered to t9161.
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-16 14:06:19 -07:00
Renamed from t/t9160-git-svn-mergeinfo-push.sh (Browse further)
