This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Branch and tag deletions

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 
<> 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 

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]