On Mon, 2 Dec 2019, Segher Boessenkool wrote: > On Fri, Nov 29, 2019 at 10:31:22PM +0000, Joseph Myers wrote: > > On Fri, 29 Nov 2019, Segher Boessenkool wrote: > > > Please post the full names of all the tags you want to delete? > > > > Here is a list of 645 tags proposed for removal, in the various > > categories I gave. Vendor tags are only included where they also fall > > into one of the other categories (e.g. tags that appear to be purely > > for merge tracking and so would not idiomatically exist in git at > > all). > > [ snip ] > > Thanks for the list. As far as I can see all of those are no longer > useful, so they could be jut deleted from the SVN repo (if everyone > else agrees!) It is much safer to delete tags after the conversion to > git, because that way it is much easier to get things back if something > is lost after all, in general.
One suggestion made in a comment on <https://gitlab.com/esr/reposurgeon/issues/170> was making reposurgeon put deleted tags and branches in refs/deleted/ so a converted version of the data would be available without being fetched by default. If that were done, the data would be in git even for tags deleted before the conversion. I should note that, while my fixes for parents of branch creation commits that cvs2svn messed up were based on manual review of all the cases my script identified as suspicious and couldn't find an automated fix for, where the branch existed in SVN at the time of the conversion to SVN (r105925), even if the branch had been deleted or renamed in SVN after then, my fixes for parents of tag creation commits were less exhaustive. My fixes for tag parents should cover all the official release tags from the CVS period, and some others, but did not try to cover any tags currently suggested to be deleted, or any vendor tags. This doesn't matter so much if you're only concerned about the contents of a tag, not its ancestry, but you should not expect that commits generated for tags in the CVS period have sensible parents except where fixed manually, because cvs2svn tended to mess up identifying parents for tags at least as much as it did for branches. (Where there are bugs affecting *contents* of a tag, e.g. issue 167, those are of course critical bugs needing fixing to consider the conversion viable.) (The typical form of bad tag parent identification is that, when the tag was of a point on a non-trunk branch, cvs2svn treated it as a copy of trunk from somewhere around the time that non-trunk branch was created from trunk, and then put a large set of changes in the tag-creation commit to give it the right contents. So it won't have much effect on the results of "git tag --contains" for commits on master, which is one thing for which tag ancestry does matter.) -- Joseph S. Myers jos...@codesourcery.com
