kernel/git - git - PowerEL Git System

39447 Commits

6 Branches

36 Tags

131 MiB

Tree: 69f9a6e54a

Commit Graph

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
Eric Wong	b186a261b1	svn: initial "master" points to trunk if possible Since "trunk" is a convention for the main development branch in the SVN world, try to make that the master branch upon initial checkout if it exists. This is probably less surprising based on user requests. t9135 was the only test which relied on the previous behavior and thus needed to be modified. Signed-off-by: Eric Wong <normalperson@yhbt.net>	16 years ago

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

Eric Wong

b186a261b1

svn: initial "master" points to trunk if possible

Since "trunk" is a convention for the main development branch in
the SVN world, try to make that the master branch upon initial
checkout if it exists.  This is probably less surprising based
on user requests.

t9135 was the only test which relied on the previous behavior
and thus needed to be modified.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

16 years ago

2 Commits (69f9a6e54a46c4a75dff680047a465d04cca20ca)