This is the mail archive of the
mailing list for the GCC project.
Re: Branch and tag deletions
- From: "Eric S. Raymond" <esr at thyrsus dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 25 Nov 2019 22:27:40 -0500
- Subject: Re: Branch and tag deletions
- References: <alpine.DEB.firstname.lastname@example.org>
- Reply-to: esr at thyrsus dot com
Joseph Myers <email@example.com>:
> I'm looking at the sets of branches and tags resulting from a GCC
> repository conversion with reposurgeon.
> 1. I see 227 branches (and one tag) with names like
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
> total in a conversion of GCC history as of a few days ago). Can we tell
> reposurgeon not to create such branches (and tags)? I can't simply do
> "branch /-deleted-r/ delete" because that command doesn't take a regular
Those dead branches were supposed to never be visible in the final
They arise when a tag is created, then deleted, then recreated under
the same name. The dumpfile operations for the old tag can't simply
ignored, as part of its content could get copied forward from before
the delete to a branch that remains live. So I recolor them, then
have logic to skip generating commits and tags from them. You;re
seeing dome leak through those guards, which is a bug.
I'm using a different and much simpler strategy in the analyzer rewrite;
this bug should be squashed when it lands.
> 2. gcc.lift has a series of "tag <something> delete" commands, generally
> deleting tags that aren't official GCC releases or prereleases (many of
> which were artifacts of how creating such tags was necessary to track
> merges in the CVS and older SVN era). But some such commands are
> mysteriously failing to work. For example I see
> tag /ZLIB_/ delete
> reposurgeon: no tags matching /ZLIB_/
> but there are tags ZLIB_1_1_3, ZLIB_1_1_4, ZLIB_1_2_1, ZLIB_1_2_3 left
> after the conversion. This isn't just an issue with regular expressions;
> I also see e.g.
> tag apple/ppc-import-20040330 delete
> reposurgeon: no tags matching apple/ppc-import-20040330
> and again that tag exists after the conversion.
I knew there was a problem with those, but I have not diagnosed it
yet. I know generally where it has to be and think it will be
relatively easy to clean up once I've dealt with the more pressing
Please file issues about these bugs so I can track then.
On the first one, it would be helpful if you could list some tags
that these match expressions fail to pick up from as early as
possible. Shortening the leading segment I need to load speeds up
my test cycle significantly,
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>