git-svn gets wrong parent revision for tags

[Thomas Leonard]

Binary package hint: git-core

When converting a subversion repository to GIT using git-svn, the svn tags do not have the right parent. Each tag should be identical to a trunk revision (which it was copied from), but because git-svn uses an earlier revision as the parent it appears that the same work was duplicated on two branches.

In the subversion history, a release tag appears like this:

$ svn log -v file:///.../zero-install/releases/0publish/0publish-0.12
r2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line
Changed paths:
   A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)
   R /releases/0publish/0publish-0.12/0publish (from /trunk/0publish/0publish:2070)
   R /releases/0publish/0publish-0.12/0publish.xml (from /trunk/0publish/0publish.xml:2070)
   R /releases/0publish/0publish-0.12/release.py (from /trunk/0publish/release.py:2069)

Released 0.12
...

The correct revision to use for the parent is 2070, but git-svn is using revision 1968:

r2070 = f229dedfe78c2dd73b66d7c5fc30d885e813ca2c (trunk)
Found possible branch point: file://.../zero-install/trunk/0publish => file://.../zero-install/releases/0publish/0publish-0.12, 1968
Found branch parent: (tags/0publish-0.12) eea1094a8eda014ea0befcd0bbc24406b298bfcf

[Thomas Leonard (talex5)]

The attached patch to git-svn fixed the problem for my repository.

[Emil Sit (emilsit)]

Hello,

What version of git are you using? Can you give a simple series of git and svn commands that demonstrate the problem? Since this sounds like an upstream git bug and this patch may affect other use cases of subversion, would you be willing to submit this bug/patch to the git developers directly (see http://git.or.cz/ or e-mail <email address hidden>)?

Thanks!

[Emil Sit (emilsit)]

Leaving as incomplete despite patch; I don't know if git's internal tests cover this case or if it is dependent on a particular way of structuring the svn repo.

[Thomas Leonard (talex5)]

Try:

git-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install -T trunk/0publish -r1890:2072 -b releases/0publish

git-svn version 1.5.2.5 (svn 1.4.4)

Go into the created 'zero-install' directory and run:

gitk --all

As you can see, the git branch comes from r1894, yet the svn log shows that in includes files from r2070:

svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install -r2071 -v

My patch is not correct in all cases, since it is possible to create a branch from an earlier revision than HEAD (probably it should find the newest source version rather than the oldest). However, the current code seems worse since in fails to cope with the normal case.

(the problem of getting the correct branch point is probably unsolvable in the most general case, since a branch may even come from a mixture of different revisions, although I doubt anyone does that intentionally)

[Emil Sit (emilsit)]

I know that git-svn may rely on various conventions for the use of git and use of svn but since I'm not really familiar with either, it sounds like this should best be handled by the upstream developers. Git does not use a dedicated bug tracker but handles issues on the mailing list <email address hidden>. If you submit your patch there, you should get a pretty fast response and you can follow up with this bug. In any event, if the bug is fixed upstream, the next version of Ubuntu will probably include the fix automatically.

Can you handle the follow-up with the official git developers? Thanks!

[Magnus S (magnuss)]

Hi,
this bug report is getting old, so i'm closing it now. If this issue is still affecting you, please reopen.
To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Thomas Leonard (talex5)]

Looks like a patch is now available:

https://kerneltrap.org/mailarchive/git/2008/12/16/4429654