kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Johan Herland	fe191fcaa5	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>	11 years ago
Jens Lehmann	fd4ec4f2bb	Several tests: cd inside subshell instead of around Fixed all places where it was a straightforward change from cd'ing into a directory and back via "cd .." to a cd inside a subshell. Found these places with "git grep -w "cd \.\.". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Eygene Ryabinkin	da083d688e	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>	16 years ago
Nanako Shiraishi	1364ff27dc	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>	17 years ago
Marcus Griep	570d35c26d	git-svn: Allow deep branch names by supporting multi-globs Some repositories use a deep branching strategy, such as: branches/1.0/1.0.rc1 branches/1.0/1.0.rc2 branches/1.0/1.0.rtm branches/1.0/1.0.gold Only allowing a single glob stiffles this. This change allows for a single glob 'set' to accept this deep branching strategy. The ref glob depth must match the branch glob depth. When using the -b or -t options for init or clone, this is automatically done. For example, using the above branches: svn-remote.svn.branches = branches//:refs/remote// gives the following branch names: 1.0/1.0.rc1 1.0/1.0.rc2 1.0/1.0.rtm 1.0/1.0.gold [ew: * removed unrelated line-wrapping changes * fixed line-wrapping in a few more places * removed trailing whitespace * fixed bashism in test * removed unnecessary httpd startup in test * changed copyright on tests to 2008 Marcus Griep * added executable permissions to new tests ] Signed-off-by: Marcus Griep <marcus@griep.us> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago