kernel/git - git - PowerEL Git System

36402 Commits

6 Branches

36 Tags

131 MiB

Tree: f2667a8330

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
David D. Kilzer	3235b7053c	git-svn: fix fetch with deleted tag Currently git-svn assumes that two tags created from the same revision will have the same repo url, so it uses a ref to the tag without checking that its url matches the current url. This causes issues when fetching an svn repo where a tag was created, deleted, and then recreated under the following circumstances: - Both tags were copied from the same revision. - Both tags had the same name. - Both tags had different repository paths. - [Optional] Both tags have a file with the same name but different content. When all four conditions are met, a checksum mismatch error occurs because the content of two files with the same path differs (see t/t9155--git-svn-fetch-deleted-tag.sh): Checksum mismatch: ChangeLog 065854.... expected: ce771b.... got: 9563fd.... When only the first three conditions are met, no error occurs but the tag in git matches the first (deleted) tag instead of the last (most recent) tag (see t/t9156-git-svn-fetch-deleted-tag-2.sh). The fix is to verify that the repo url for the ref matches the current url. If the urls do not match, then a "tail" is grown on the tag name by appending a dash and rechecking the new ref's repo url until either a matching repo url is found or a new tag is created. Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net> Acked-by: Eric Wong <normalperson@yhbt.net>	15 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

David D. Kilzer

3235b7053c

git-svn: fix fetch with deleted tag

Currently git-svn assumes that two tags created from the same
revision will have the same repo url, so it uses a ref to the
tag without checking that its url matches the current url.

This causes issues when fetching an svn repo where a tag was
created, deleted, and then recreated under the following
circumstances:

- Both tags were copied from the same revision.
- Both tags had the same name.
- Both tags had different repository paths.
- [Optional] Both tags have a file with the same name but
  different content.

When all four conditions are met, a checksum mismatch error
occurs because the content of two files with the same path
differs (see t/t9155--git-svn-fetch-deleted-tag.sh):

    Checksum mismatch: ChangeLog 065854....
    expected: ce771b....
         got: 9563fd....

When only the first three conditions are met, no error occurs
but the tag in git matches the first (deleted) tag instead of
the last (most recent) tag (see
t/t9156-git-svn-fetch-deleted-tag-2.sh).

The fix is to verify that the repo url for the ref matches the
current url.  If the urls do not match, then a "tail" is grown
on the tag name by appending a dash and rechecking the new ref's
repo url until either a matching repo url is found or a new tag
is created.

Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

15 years ago

2 Commits (f2667a83304a9fa4910240b64f9d3b1c640e6743)