#501761 git-svn --tags should at least /try/ to handle tags as tags

Package:
git-svn
Source:
git
Submitter:
Gerfried Fuchs
Date:
2010-11-29 04:21:03 UTC
Severity:
wishlist
#501761#5
Date:
2008-10-10 07:19:43 UTC
From:
To:
        Hi!

 git-svn -s (or --tags=) assumes that all tags subdirectories can be
changed and doesn't even try to use tags but creates branches right
ahead. When wanting to convert from svn to git this is really a pain,
and I don't see why it has to be done that way. When a second revision
in a tags directory appears it shouldn't be complicated to convert the
tag into a branch and apply that revision to the branch (and propably
also remove the original tag).

 As this does hinder proper conversion from svn to git having it noted
as bug instead of wishlist is more proper in my opinion - hope you can
agree.

 Thanks,
Rhonda
#501761#10
Date:
2008-11-05 00:43:43 UTC
From:
To:
severity 501761 wishlist
quit

Hi, I'm pretty sure this has been discussed upstream more than once.  I
personally think it's just fine to handle 'tags' in svn, which actually
are branches, as branches by default, and so might tag this report
WONTFIX.  If you strongly want your change happen, please try to
convince upstream.

Thanks, Gerrit.
#501761#17
Date:
2009-02-07 07:17:41 UTC
From:
To:
usertags 501761 + bittenby
thanks

I would suggest that the correct behaviour for git-svn is the following.

Where SVN branch points are found and there are no changes in the branch
commit, then the branch point is created as a tag. If the SVN branch
then gets further commits later, the git tag is converted to a branch.

This gives sane behaviour when SVN's branches are used as tags and sane
behaviour when they are actually used as branches.

It also saves people using git-svn to completely switch from SVN to git
from having to manually delete branches and manually create tags
corresponding to the deleted branches during the conversion.
#501761#22
Date:
2009-05-12 14:24:49 UTC
From:
To:
tagging the known working cases and leaving the rest of them as branches
would work, but would leave you with a slightly inconsistant result (i.e.
you'd also probably want to warn the user that they're missing some tags).

here's a few more alternatives for consideration:

option 1:

do the same as the previous suggestion, but instead of "leave as branch",
tag the head (instead of the parent), and leave it as a headless commit.

pros: everything is consistantly a tag
cons: you end up with some headless commits for the corner cases

option 2:

rename the tags branches as "svn-tags" and tag the heads of the branches
as tags

pros: truer to the actual history, very simple, possibly idempotent
cons: extra and arguably ugly branch history

option 3:

in the non-trivial case, tag the head of the branch, and rewrite the
history so that it appears to directly branch from the common
ancestor (i.e. graft) and rebasing (i.e. filter-branch) it to make the
graft integrated into the repo history.

this is basically option 1 plus some git vodoo to prevent the ancestry
history of the otherwise headless commit from being lost.

pros: should cover corner cases more gracefully
cons: more complicated, changes history.
#501761#29
Date:
2010-11-28 18:03:49 UTC
From:
To:
Hi,

Sorry for the long silence.

sean finney wrote:
[...]
[...]
[...]

The problem with all these choices is that git (by design) does not
make changing tags easy.  While your local version of the tag would
advance as that tag-branch advances, others who fetch from you would
not notice.

Even worse, in the solutions that involve just deleting a tag, others
who fetch from you would keep the old tag but get the new branch, too,
so the result of

	git log v9.29.3

would be missing recent revisions but "git log origin/v9.29.3" would
not.  Confusing.

Musings:

. Any change would be confusing. :)  If this gets implemented in
  git svn, it should be enabled by an option.

. The ideal would be to (1) _always_ fetch tags as tags and
  (2) disallow tag fixup revs altogether, unless some sort of --force
  option is used.  This would more closely match current git practice
  (see "On Re-tagging" in the "git tag" manual).

Thoughts on this would be very helpful because the same questions come
up in implementing "native" svn support for git.

Regards,
Jonathan
#501761#34
Date:
2010-11-29 03:05:59 UTC
From:
To:
At the very least git svn --convert should do these:

     1. SVN tags that are actually tags in SVN (ie dir copies with no
        non-copy commits) are converted to git tags.
     2. SVN tags that are actually branches in SVN despite being labeled
        tags (these exist unfortunately) are left as branches.
#501761#39
Date:
2010-11-29 04:06:16 UTC
From:
To:
Paul Wise wrote:

... and what happens when a tag changes from (1) to (2)?
#501761#44
Date:
2010-11-29 04:16:50 UTC
From:
To: