Hi,
Sorry for the long silence.
sean finney wrote:
> 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:
[...]
> 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.
[...]
> rename the tags branches as "svn-tags" and tag the heads of the branches
> as tags
[...]
> basically option 1 plus some git vodoo to prevent the ancestry
> history of the otherwise headless commit from being lost.
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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
