Branch and tag deletions

Branch and tag deletions

[Joseph Myers]

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

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.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 
> expression.

Those dead branches were supposed to never be visible in the final
conversion.

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

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>

Re: Branch and tag deletions

[Joseph Myers]

On Mon, 25 Nov 2019, Eric S. Raymond wrote:

> 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
> issues.
> 
> 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,

Comment added on issue 165 pointing to specific tags that wrongly failed 
to get deleted.

Another comment added on issue 165 regarding cases where a tag deletion 
command deleted only a subset of the matching tags, since it seems 
plausible the underlying issue could be the same.

Issue 166 filed for the deleted-r branches and tags staying around.

Issue 167 filed for the loss of the changes from the commit for the 
gcc-2_95_3 tag.

In all cases, my testing includes changes from my merge requests for the 
gcc-conversion repository, rather than being based on the unmodified 
upstream state of that repository, but I don't have any reason to think 
these bugs depend on those changes.

A further note: in a previous run of the conversion I didn't see any 
emptycommit-* tags.  In my most recent conversion run, I see 4070 such 
tags.  How do I tell reposurgeon never to create such tags?  Or should I 
add a tag deletion command for them in gcc.lift, once tag deletion is 
working reliably?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> A further note: in a previous run of the conversion I didn't see any 
> emptycommit-* tags.  In my most recent conversion run, I see 4070 such 
> tags.  How do I tell reposurgeon never to create such tags?  Or should I 
> add a tag deletion command for them in gcc.lift, once tag deletion is 
> working reliably?

That's what tag deletion by regexp is for.

One of reposurgeon's design rules is "never add a special-purpose switch
or flag when an application of the selection-set minilanfuage will do"
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 26 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > A further note: in a previous run of the conversion I didn't see any 
> > emptycommit-* tags.  In my most recent conversion run, I see 4070 such 
> > tags.  How do I tell reposurgeon never to create such tags?  Or should I 
> > add a tag deletion command for them in gcc.lift, once tag deletion is 
> > working reliably?
> 
> That's what tag deletion by regexp is for.

Thanks.  We've accumulated a lot of merge requests on the gcc-conversion 
repository, once those are merged I'll test a further change to remove 
those tags.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> Thanks.  We've accumulated a lot of merge requests on the gcc-conversion 
> repository, once those are merged I'll test a further change to remove 
> those tags.

I just checked; a rebase button appeared on your MRs and I merged all
three, but no rebase option occurs on Richard Earnshaw's reqyests.

The GitLab interface seems fickle and arbitrary at times.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 26 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > Thanks.  We've accumulated a lot of merge requests on the gcc-conversion 
> > repository, once those are merged I'll test a further change to remove 
> > those tags.
> 
> I just checked; a rebase button appeared on your MRs and I merged all
> three, but no rebase option occurs on Richard Earnshaw's reqyests.

Yes, I managed to locate the (not very obvious) "Allow commits from 
members who can merge to the target branch." checkbox in the MR edit 
interface to allow that.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Maxim Kuvyrkov]

> On Nov 25, 2019, at 7:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> 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 
> expression.
> 
> 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.

IMO, we should aim to convert complete SVN history frozen at a specific point.  So that if we don't want to convert some of the branches or tags to git, then we should delete them from SVN repository before conversion.

Otherwise it will (a) complicate comparison or repos converted by different tools, and (b) will require us to remember why parts of SVN history were not converted to git.

My conversion at https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ contains all branches and tags present in current SVN repo.

--
Maxim Kuvyrkov
https://www.linaro.org

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote:

> IMO, we should aim to convert complete SVN history frozen at a specific 
> point.  So that if we don't want to convert some of the branches or tags 
> to git, then we should delete them from SVN repository before 
> conversion.

Sure, we could do that.  Eric, can you confirm that, with current 
reposurgeon, if a branch or tag was deleted in SVN and does not appear in 
the final revision of /branches or /tags, it should not appear in the 
resulting converted repository, so that any cases where reposurgeon fails 
to reflect such a deletion-in-SVN should be reported as a reposurgeon bug?  
And that the same applies where a branch or tag was renamed - that only 
the new name, not the old one, should appear in the converted repository?  
There are quite a few deletions in gcc.lift for tags that do not actually 
appear in /tags in the current SVN repository, but I'm not sure how many 
are actually relevant with current reposurgeon.

Then there is the policy question to resolve about which tags we actually 
want to keep (I'm presuming we want to keep essentially all branches by 
default, absent any clear malformations that make us decide to delete a 
given branch).  Tags in the following classes make up the bulk of those 
currently in the SVN repository, and right now are deleted in gcc.lift 
under the comment "Tentative tag removals - might be backed out":

(a) Tags for branchpoints and tracking merge status - largely from the CVS 
era when they were needed to work around the lack of a global version 
number for the whole source tree, but also from the early SVN era when 
there were global revision numbers but SVN merge tracking hadn't yet been 
implemented.

(b) Tags for vendor-branch imports of third-party software (maybe tagging 
just part of the source tree, in the CVS era).  That's the GC_*, LIBTOOL_* 
and ZLIB_* tags, for example.

(c) Tags for other (non-GCC) projects, from when ,v files were linked 
between different repositories (most of those have already been deleted in 
SVN, however).

(d) Tags for snapshots (most of those have already been deleted in SVN, 
however).

(e) Tags with the same names as branches (at least three of them).  
Formally that's valid in git just as it is in SVN - there's no conflict 
between refs/heads/<name> and refs/tags/<name> - but in practice it's 
confusing and such tags were surely created by mistake.

(f) Tags for distributor releases as opposed to official GCC / EGCS 
releases.


All of the above except for (f) are not particularly idiomatic to have in 
git, simply because git tracks merges and a global commit identifier can 
be used to refer to a snapshot etc. rather than needing a tag.  (Because 
SVN does merge tracking, I don't think many tags in the classes (a) 
through (e) have been created recently in SVN either - they are generally 
from the CVS or early SVN eras, or created by mistake.)

So what do people think about tags in the above classes?  Should some or 
all of those be deleted in SVN?

(Note: my checks of parents for cvs2svn-created tags were limited to those 
currently kept by gcc.lift.  If we decide to keep more tags from the 
cvs2svn era I'll need to run further checks of tag parents.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote:
> 
> > IMO, we should aim to convert complete SVN history frozen at a specific 
> > point.  So that if we don't want to convert some of the branches or tags 
> > to git, then we should delete them from SVN repository before 
> > conversion.
> 
> Sure, we could do that.  Eric, can you confirm that, with current 
> reposurgeon, if a branch or tag was deleted in SVN and does not appear in 
> the final revision of /branches or /tags, it should not appear in the 
> resulting converted repository, so that any cases where reposurgeon fails 
> to reflect such a deletion-in-SVN should be reported as a reposurgeon bug?

Confirmed.

The ontological mismatch between the Subversion and Git data models actually
*forces* us to pick a preferred view and discard tags and branches
that are not visible from that view. For obvious reasons reposurgeon chooses
the view backwards from the end of the history, so it will be the most
recent incarnation of each tag and branch that you see.

There is an alternative, the --nobranch conversion. This would preserve the
entire historical structure, including deleted tags and branches, but the
cost is that the conversion doesn't have git tags and branches itself - 
it's just one big directory history on /refs/heads/master.  While this is useful
for forensics, it is not a conversion you'd want to use for production.

> And that the same applies where a branch or tag was renamed - that only 
> the new name, not the old one, should appear in the converted repository? 

Confirmed, see above.

> There are quite a few deletions in gcc.lift for tags that do not actually 
> appear in /tags in the current SVN repository, but I'm not sure how many 
> are actually relevant with current reposurgeon.

Many will not be.  The recipe file predates the point at which I came
to fully undersrand the ramifications of tag delete/recreate sequences.
I haven't cleaned it up yet because chasing down the last few bugs in
the analyzer is more important.

I'll leave it to you guys to discuss the policy issues.  In general I
think you can safely throw out branchphoint tagas and emptycommits;
reposurgeon only preserves those on the theoretical chance that there
might be something interesting in the change comments.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Eric S. Raymond wrote:

> > Sure, we could do that.  Eric, can you confirm that, with current 
> > reposurgeon, if a branch or tag was deleted in SVN and does not appear in 
> > the final revision of /branches or /tags, it should not appear in the 
> > resulting converted repository, so that any cases where reposurgeon fails 
> > to reflect such a deletion-in-SVN should be reported as a reposurgeon bug?
> 
> Confirmed.

Thanks.

My current test conversion run is testing two changes: deleting 
emptycommit tags, and using --user-ignores to prefer the .gitignore file 
in SVN over one auto-generated from svn:ignore properties.  For the next 
one after that I'll try eliminating all branch/tag removals that shouldn't 
be doing anything, based on the current sets of branches and tags in SVN, 
and report bugs if I see anything appearing in the converted repository 
that shouldn't be.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> My current test conversion run is testing two changes: deleting 
> emptycommit tags, and using --user-ignores to prefer the .gitignore file 
> in SVN over one auto-generated from svn:ignore properties.  For the next 
> one after that I'll try eliminating all branch/tag removals that shouldn't 
> be doing anything, based on the current sets of branches and tags in SVN, 
> and report bugs if I see anything appearing in the converted repository 
> that shouldn't be.

I'm more worried about missing files. I saw a bunch of those on my
last test.  This could be spurious - the elaborate set of branch
mappings you specified confuses my validation test, because there is
no longer a 1-1 corresponsence between Subversion and git branches.

The next test I run I'm going to comment out your branch mappings.
If I get a validated conversion out of that I think it's all over
but the cleanup and policy tinkering.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > My current test conversion run is testing two changes: deleting 
> > emptycommit tags, and using --user-ignores to prefer the .gitignore file 
> > in SVN over one auto-generated from svn:ignore properties.  For the next 
> > one after that I'll try eliminating all branch/tag removals that shouldn't 
> > be doing anything, based on the current sets of branches and tags in SVN, 
> > and report bugs if I see anything appearing in the converted repository 
> > that shouldn't be.
> 
> I'm more worried about missing files. I saw a bunch of those on my
> last test.  This could be spurious - the elaborate set of branch
> mappings you specified confuses my validation test, because there is
> no longer a 1-1 corresponsence between Subversion and git branches.

I'm hoping any such missing file problems come from bugs in the old SVN 
dump reader with complicated commits mixing copies / deletions / 
replacements with copies from other locations and that your rewrite will 
fix the semantics in such cases.

All the current gcc-conversion merge requests, both mine and Richard's, 
should now be set to allow rebasing.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> > I'm more worried about missing files. I saw a bunch of those on my
> > last test.  This could be spurious - the elaborate set of branch
> > mappings you specified confuses my validation test, because there is
> > no longer a 1-1 corresponsence between Subversion and git branches.
> 
> I'm hoping any such missing file problems come from bugs in the old SVN 
> dump reader with complicated commits mixing copies / deletions / 
> replacements with copies from other locations and that your rewrite will 
> fix the semantics in such cases.

Also possible.  

The old code was a hairball. The new code is a bunch of relatively simple
sequential passes - 10 so far, final version likely to have 12 or 13 - with
well-defined preconditions and exit contracts. If nothing else this is
going to make troubleshooting any remaining defects much easier.

> All the current gcc-conversion merge requests, both mine and Richard's, 
> should now be set to allow rebasing.

They were, and are all merged now, except for one that Richard just landed. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 26 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > A further note: in a previous run of the conversion I didn't see any 
> > emptycommit-* tags.  In my most recent conversion run, I see 4070 such 
> > tags.  How do I tell reposurgeon never to create such tags?  Or should I 
> > add a tag deletion command for them in gcc.lift, once tag deletion is 
> > working reliably?
> 
> That's what tag deletion by regexp is for.

One more observation on that: in my last test conversion, deleting the 
emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the 
conversion was spent just deleting those tags).  Deleting tags matching 
/-root$/ took about half an hour.  So I think there is a performance issue 
somewhere with (some cases of) tag deletion by regexp, at least when the 
regexp matches a large number of tags (but some other bulk deletions seem 
to run much quicker per tag).  Taking a few seconds per tag is fine for an 
individual deletion, but a problem when you want to delete 4070 tags at 
once.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> One more observation on that: in my last test conversion, deleting the 
> emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the 
> conversion was spent just deleting those tags).  Deleting tags matching 
> /-root$/ took about half an hour.  So I think there is a performance issue 
> somewhere with (some cases of) tag deletion by regexp, at least when the 
> regexp matches a large number of tags (but some other bulk deletions seem 
> to run much quicker per tag).  Taking a few seconds per tag is fine for an 
> individual deletion, but a problem when you want to delete 4070 tags at 
> once.

File that as an issue, please. Go has very good profiling tools, finding
the hotspot(s) in situations like this is easy and thus we should be able to
fix this quickly when it reaches the top of the priority list,
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > One more observation on that: in my last test conversion, deleting the 
> > emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the 
> > conversion was spent just deleting those tags).  Deleting tags matching 
> > /-root$/ took about half an hour.  So I think there is a performance issue 
> > somewhere with (some cases of) tag deletion by regexp, at least when the 
> > regexp matches a large number of tags (but some other bulk deletions seem 
> > to run much quicker per tag).  Taking a few seconds per tag is fine for an 
> > individual deletion, but a problem when you want to delete 4070 tags at 
> > once.
> 
> File that as an issue, please. Go has very good profiling tools, finding
> the hotspot(s) in situations like this is easy and thus we should be able to
> fix this quickly when it reaches the top of the priority list,

https://gitlab.com/esr/reposurgeon/issues/169 filed for this performance 
issue.

https://gitlab.com/esr/reposurgeon/issues/170 filed for deleted branches 
and tags wrongly reappearing in the conversion.

https://gitlab.com/esr/gcc-conversion/merge_requests/17 filed for my 
latest rearrangement of tag/branch deletions to help the review of which 
we actually want to delete, commenting out those that ought not be 
necessary any more (many of which then wrongly appear in the conversion 
because of reposurgeon issue 170).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Richard Biener]

On Thu, Nov 28, 2019 at 5:46 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Wed, 27 Nov 2019, Eric S. Raymond wrote:
>
> > Joseph Myers <joseph@codesourcery.com>:
> > > One more observation on that: in my last test conversion, deleting the
> > > emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the
> > > conversion was spent just deleting those tags).  Deleting tags matching
> > > /-root$/ took about half an hour.  So I think there is a performance issue
> > > somewhere with (some cases of) tag deletion by regexp, at least when the
> > > regexp matches a large number of tags (but some other bulk deletions seem
> > > to run much quicker per tag).  Taking a few seconds per tag is fine for an
> > > individual deletion, but a problem when you want to delete 4070 tags at
> > > once.
> >
> > File that as an issue, please. Go has very good profiling tools, finding
> > the hotspot(s) in situations like this is easy and thus we should be able to
> > fix this quickly when it reaches the top of the priority list,
>
> https://gitlab.com/esr/reposurgeon/issues/169 filed for this performance
> issue.
>
> https://gitlab.com/esr/reposurgeon/issues/170 filed for deleted branches
> and tags wrongly reappearing in the conversion.
>
> https://gitlab.com/esr/gcc-conversion/merge_requests/17 filed for my
> latest rearrangement of tag/branch deletions to help the review of which
> we actually want to delete, commenting out those that ought not be
> necessary any more (many of which then wrongly appear in the conversion
> because of reposurgeon issue 170).

Can't branches and tags be deleted after the conversion as well?

Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

On Fri, 29 Nov 2019, Richard Biener wrote:

> Can't branches and tags be deleted after the conversion as well?

Yes (manually on the server, depending on the exact configuration we set 
up for what pushes are allowed), but deleting before conversion speeds up 
the process of verifying conversion correctness at branch tips and makes 
different conversions more comparable.

These are the current commented tag deletions from my most recent merge 
request which sorts them into logical groups.  I suggest we consider which 
of these we wish to delete, and also suggest that the answer should be all 
except maybe the vendor tags.  Note that some tags may be covered in more 
than one group, and the tag deletions by regexp include tags in 
subdirectories that match that regexp.

# Various tags with names that are meaningless in the context of the
# GCC repository.
tag ChangeLog delete
tag Ver01 delete
tag r2_00-beta delete
tag release-0-0 delete
tag release-0-1 delete
tag release-1-0 delete

# Tags to mark branchpoints (a CVS idiom, not relevant in git).
tag /branchpoint/ delete
# These branchpoint tags are also confusing by having the same names
# as the branches.
tag c++-compat-branch delete
tag cxx-reflection-branch delete

# Tags for external components imported as vendor branches or similar.
tag /GC_/ delete
tag /LIBTOOL_/ delete
tag /ZLIB_/ delete
tag stl-3_11 delete
tag stl-971028 delete
# Not sure exactly what this tag is for.
tag gettext_0_10_35 delete

# Tags for imports in general.
tag /import/ delete

# Other tags used to mark merge information.
tag /merge|before|after/ delete
tag cp-parser-mege-14 delete
tag ix86/gcc-4_1-branch delete
tag ix86/gcc-4_2-branch delete
# This merge tag is also confusing by having the same name as the branch.
tag function-specific-branch delete

# Snapshot tags (most have been deleted in SVN), including vendor
# snapshots.
tag /snapshot/ delete
tag bounded-pointers-ss-20000730 delete
tag gcc-3_0_pre_20010525 delete
tag gcc_3_0_pre_20010527 delete
tag gcc-3_3-e500-ss-20030904 delete
tag gcc-3-5-20040503 delete
tag libiberty_19980515 delete

# Dated tags that might be snapshots or imports or just a particular
# point on a branch.
tag devo_gcc_testsuite_970818 delete
tag etc_19980515 delete
tag f_torture_10011997 delete
tag java-gui-update-20040619 delete
tag objc-improvements-candidate-20030915 delete
tag objc-improvements-candidate-20030922 delete
tag pch-commit-20020603 delete

# Tags for a particular point on a development branch.
tag immuse-rewrite-abstract delete
tag immuse-rewrite-alpha delete
tag immuse-rewrite-beta delete
tag immuse-rewrite-start delete
tag itanium_sched_branch_251102 delete
tag pre-cni-catch-change delete

# Tags for vendor releases.
tag /ARM/ delete
tag /apple/gcc/ delete
tag /csl/ delete
tag /linaro-/ delete
tag /microblaze-/ delete
tag /st/GCC/ delete
tag /ubuntu/gcc-/ delete
tag egcs_1_0_x_redhat5_1 delete
tag gcc-1766 delete
tag gcc-3_2-rhl8-3_2-7 delete
tag ix86/gcc_4_3_1_release delete

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 29/11/2019 16:14, Joseph Myers wrote:
> # Tags for vendor releases.
> tag/ARM/  delete
> tag/apple/gcc/  delete
> tag/csl/  delete
> tag /linaro-/ delete
> tag /microblaze-/ delete
> tag/st/GCC/  delete
> tag /ubuntu/gcc-/ delete
> tag egcs_1_0_x_redhat5_1 delete
> tag gcc-1766 delete
> tag gcc-3_2-rhl8-3_2-7 delete
> tag ix86/gcc_4_3_1_release delete

I'm not convinced these should be just deleted.  At least, not without 
the specific vendor's agreement.  But perhaps they should not be in the 
default refs/tags namespace.

The same also applies for the vendor branches, perhaps we should have 
some useful conventions for these, something like

refs/vendors/<vendor>/{heads,tags}

And similarly if users want private development trees:

refs/users/<user>/{heads,tags}

Git wouldn't pull either of these by default, which would help to 
minimise the amount of data pulled, but adding them to a pull spec would 
be trivial.

I also wonder whether in the standard namespaces we should be a bit more 
structured, so that only releases use single-level tags, and everything 
else goes into refs/{heads,tags}/devel.  Or we could do it the other way 
around, so all releases go into refs/{heads,tags}/releases - that makes 
finding them amongst the noise of other tag/branch names much easier.

R.

Re: Branch and tag deletions

[Joseph Myers]

On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:

> I'm not convinced these should be just deleted.  At least, not without the
> specific vendor's agreement.  But perhaps they should not be in the default
> refs/tags namespace.

What about the other tags I listed?  Can we get agreement on deleting some 
or all of those classes of tags that are not vendor tags?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Segher Boessenkool]

On Fri, Nov 29, 2019 at 04:57:30PM +0000, Joseph Myers wrote:
> On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
> 
> > I'm not convinced these should be just deleted.  At least, not without the
> > specific vendor's agreement.  But perhaps they should not be in the default
> > refs/tags namespace.
> 
> What about the other tags I listed?  Can we get agreement on deleting some 
> or all of those classes of tags that are not vendor tags?

Please post the full names of all the tags you want to delete?


Segher

Re: Branch and tag deletions

[Joseph Myers]

On Fri, 29 Nov 2019, Segher Boessenkool wrote:

> On Fri, Nov 29, 2019 at 04:57:30PM +0000, Joseph Myers wrote:
> > On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
> > 
> > > I'm not convinced these should be just deleted.  At least, not without the
> > > specific vendor's agreement.  But perhaps they should not be in the default
> > > refs/tags namespace.
> > 
> > What about the other tags I listed?  Can we get agreement on deleting some 
> > or all of those classes of tags that are not vendor tags?
> 
> 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).

Specific tags (only this exact name rather than coming from a regexp):

# Various tags with names that are meaningless in the context of the
# GCC repository.
/tags/ChangeLog
/tags/Ver01
/tags/r2_00-beta
/tags/release-0-0
/tags/release-0-1
/tags/release-1-0

# Tags to mark branchpoints (a CVS idiom, not relevant in git).
# These branchpoint tags are also confusing by having the same names
# as the branches.
/tags/c++-compat-branch
/tags/cxx-reflection-branch

# Tags for external components imported as vendor branches or similar.
/tags/stl-3_11
/tags/stl-971028
# Not sure exactly what this tag is for.
/tags/gettext_0_10_35

# Other tags used to mark merge information.
/tags/cp-parser-mege-14
/tags/ix86/gcc-4_1-branch
/tags/ix86/gcc-4_2-branch
# This merge tag is also confusing by having the same name as the branch.
/tags/function-specific-branch

# Snapshot tags (most have been deleted in SVN), including vendor
# snapshots.
/tags/bounded-pointers-ss-20000730
/tags/gcc-3_0_pre_20010525
/tags/gcc_3_0_pre_20010527
/tags/gcc-3_3-e500-ss-20030904
/tags/gcc-3-5-20040503
/tags/libiberty_19980515

# Dated tags that might be snapshots or imports or just a particular
# point on a branch.
/tags/devo_gcc_testsuite_970818
/tags/etc_19980515
/tags/f_torture_10011997
/tags/java-gui-update-20040619
/tags/objc-improvements-candidate-20030915
/tags/objc-improvements-candidate-20030922
/tags/pch-commit-20020603

# Tags for a particular point on a development branch.
/tags/immuse-rewrite-abstract
/tags/immuse-rewrite-alpha
/tags/immuse-rewrite-beta
/tags/immuse-rewrite-start
/tags/itanium_sched_branch_251102
/tags/pre-cni-catch-change

Tags in non-vendor categories, coming from regexps:

# Tags to mark branchpoints (a CVS idiom, not relevant in git).
# /branchpoint/
/tags/Netlib_branchpoint
/tags/autovect-branchpoint
/tags/bje-unsw-branchpoint
/tags/bounded-pointers-branchpoint
/tags/cfg-branchpoint
/tags/cfo-branchpoint-2004-11-15
/tags/classpath-095-merge-branchpoint
/tags/compile-server-branchpoint
/tags/condexec-branchpoint
/tags/cp-parser-branchpoint
/tags/csl-3_4_3-linux-branchpoint
/tags/csl-arm-2004-q3-branchpoint
/tags/csl-arm-branchpoint
/tags/csl-gxxpro-3_4-branchpoint
/tags/csl-hpux-branchpoint
/tags/csl-ppc4xx-branchpoint
/tags/csl-sol210-3_4-branchpoint
/tags/csl-sol210-branchpoint
/tags/cygwin-mingw-gcc-3_2-branchpoint
/tags/dataflow-branchpoint
/tags/dfa-branchpoint
/tags/dfp-branchpoint
/tags/edge-vector-branchpoint
/tags/egcs_1_00_branchpoint
/tags/egcs_1_1_branchpoint
/tags/egcs_gc_branchpoint
/tags/ffixinc-branchpoint
/tags/fixincl-branchpoint
/tags/gcc-2_95-branchpoint
/tags/gcc-3_0-branchpoint
/tags/gcc-3_1-branchpoint
/tags/gcc-3_2-branchpoint
/tags/gcc-3_3-branchpoint
/tags/gcc-3_3-e500-branchpoint
/tags/gcc-3_3-rhl-branchpoint
/tags/gcc-3_4-branchpoint
/tags/gcc-3_4-e500-branchpoint
/tags/gcc-3_5-integration-branchpoint
/tags/gcc-4_0-branchpoint
/tags/gcj-abi-2-dev-branchpoint
/tags/gcjx-branchpoint
/tags/gnu-win32-b20-branchpoint
/tags/gomp-20050608-branchpoint
/tags/gupc-5-0-branchpoint
/tags/gupc-6-branchpoint
/tags/hammer-3_3-branchpoint
/tags/hot-cold-branchpoint
/tags/ia64-fp-model-branchpoint
/tags/immuse-rewrite-branchpoint
/tags/improved-aliasing-branchpoint
/tags/ipa-branchpoint
/tags/itanium-sched-branchpoint
/tags/java-gui-20050128-branchpoint
/tags/java-gui-branchpoint
/tags/killloop-branchpoint
/tags/libada-branchpoint
/tags/libada-gnattools-branchpoint
/tags/libgcj-2_95-branchpoint
/tags/libobjc-branchpoint
/tags/libstdcxx_so_7-branchpoint
/tags/lno-branchpoint
/tags/loop-nest-optimizer-branchpoint
/tags/merged-arm-thumb-backend-branchpoint
/tags/mips-3_4-rewrite-branchpoint
/tags/new-abi-branchpoint
/tags/new-regalloc-branchpoint
/tags/new_ia32_branchpoint
/tags/newppc-branchpoint
/tags/objc-improvements-branchpoint
/tags/pch-branchpoint
/tags/pchgc-branchpoint
/tags/premerge-fsf-branchpoint
/tags/reload-branchpoint
/tags/rtlopt-branchpoint
/tags/sh-elf-3_5-branchpoint
/tags/sh-elf-4_1-branchpoint
/tags/simplify-dom-branchpoint
/tags/ssaupdate-branchpoint
/tags/static-tree-branchpoint
/tags/stree-branchpoint
/tags/struct-reorg-branchpoint
/tags/subreg-byte-branchpoint
/tags/toplevel-bootstrap-branchpoint
/tags/tree-serialize-branchpoint
/tags/var-tracking-assignments-branchpoint
/tags/var-tracking-assignments-merge-132391-trunk-4_3-branchpoint
/tags/var-tracking-assignments-merge-145121-trunk-4_4-branchpoint
/tags/x86-64-branchpoint
/tags/apple/200511-release-branchpoint
/tags/apple/local-200502-branchpoint
/tags/apple/ppc-branchpoint
/tags/ubuntu/gcc-4_2-branchpoint

# Tags for external components imported as vendor branches or similar.
# /GC_/
/tags/GC_4_13_ALPHA_2
/tags/GC_4_14
/tags/GC_5_0
/tags/GC_5_0_ALPHA_4
/tags/GC_5_0_ALPHA_6
/tags/GC_5_0_ALPHA_7
/tags/GC_5_1
/tags/GC_6_0
/tags/GC_6_0_ALPHA_7
/tags/GC_6_1_ALPHA_1
/tags/GC_6_1_ALPHA_3
/tags/GC_6_3
/tags/GC_6_3_ALPHA_1
/tags/GC_6_6
# /LIBTOOL_/
/tags/LIBTOOL_1_3_4
/tags/LIBTOOL_1_4a_20000910
/tags/LIBTOOL_1_5_0
# /ZLIB_/
/tags/ZLIB_1_1_3
/tags/ZLIB_1_1_4
/tags/ZLIB_1_2_1
/tags/ZLIB_1_2_3

# Tags for imports in general.
# /import/
/tags/classpath-import-0_18
/tags/classpath-import-20050715
/tags/apple/ppc-import-20040330

# Other tags used to mark merge information.
# /merge|before|after/
/tags/after-GEN_INT-fixes
/tags/after-merge-3_4-csl-arm-8
/tags/after-merge-3_4-csl-sol210-3_4-1
/tags/after-merge-971021
/tags/after-merge-HEAD-csl-arm-1
/tags/after-merge-HEAD-csl-arm-2
/tags/after-merge-csl-arm-csl_3_4_3-linux-2
/tags/after-merge-etc-980515
/tags/after-merge-gcc-2-8
/tags/after-merge-gcc-2-8-0
/tags/after-merge-gcc2-980502
/tags/after-merge-gcc2-980609
/tags/after-merge-gcc2-980929
/tags/after-merge-gcc2-990109
/tags/after-merge-libiberty-980515
/tags/amigados-merge
/tags/autovect-last-merge
/tags/autovect-merge-20041213
/tags/autovect-merge-20050127
/tags/autovect-merge-20050406
/tags/autovect-merge-20050906
/tags/before-GEN_INT-fixes
/tags/before-g77-0_5_22-merge
/tags/before-merge-3_4-csl-arm
/tags/before-merge-3_4-csl-arm-4
/tags/before-merge-3_4-csl-arm-5
/tags/before-merge-3_4-csl-arm-6
/tags/before-merge-3_4-csl-arm-7
/tags/before-merge-3_4-csl-arm-8
/tags/before-merge-3_4-csl-sol210-3_4-1
/tags/before-merge-971021
/tags/before-merge-HEAD-csl-arm-1
/tags/before-merge-HEAD-csl-arm-2
/tags/before-merge-HEAD-csl-sol210-1
/tags/before-merge-csl-arm-csl_3_4_3-linux-2
/tags/before-merge-csl-sol210-3_4-csl-sol210-1
/tags/before-merge-etc-980515
/tags/before-merge-gcc-2-8
/tags/before-merge-gcc-2-8-0
/tags/before-merge-gcc2-980401
/tags/before-merge-gcc2-980502
/tags/before-merge-gcc2-980609
/tags/before-merge-gcc2-980929
/tags/before-merge-gcc2-990109
/tags/before-merge-libiberty-980515
/tags/before-miles-orphaned-changes
/tags/before-thomas-posix1996
/tags/before1204merge
/tags/before_gc_merge_981008
/tags/before_gc_merge_990327
/tags/before_gc_merge_990902
/tags/bnw-simple-merge-20021001
/tags/bounded-pointers-merge-20000421
/tags/bounded-pointers-merge-20000501
/tags/bounded-pointers-merge-20000519
/tags/bounded-pointers-merge-20000530
/tags/bounded-pointers-merge-20000619
/tags/bounded-pointers-merge-20000630
/tags/bounded-pointers-merge-20000718
/tags/bounded-pointers-merge-20000730
/tags/bounded-pointers-merge-20000811
/tags/bounded-pointers-merge-20000824
/tags/bounded-pointers-merge-20000829
/tags/bounded-pointers-merge-20000907
/tags/bounded-pointers-merge-20000914
/tags/bounded-pointers-merge-20000918
/tags/bounded-pointers-merge-20000924
/tags/bounded-pointers-merge-20001014
/tags/bounded-pointers-merge-20010106
/tags/cfg-merge-20011122
/tags/cfg-merge-20011214
/tags/cfg-merge-20011229
/tags/cfg-merge-20020204
/tags/cfg-merge-20020406
/tags/cfg-merge-20020503
/tags/cfg-merge-20020701
/tags/cfg-merge-20020805
/tags/cfg-merge-20020902
/tags/cfg-merge-20021001
/tags/cfg-merge-20021203
/tags/cfg-merge-20021206
/tags/cfg-merge-20021401
/tags/cfg-merge-20021404
/tags/cfg-merge-20021505
/tags/cfg-merge-20021906
/tags/cfg-merge-20022102
/tags/cfg-merge-20022203
/tags/cfg-merge-20022205
/tags/cfg-merge-20022301
/tags/cfg-merge-20022404
/tags/cfg-merge-20022405
/tags/cfg-merge-20022802
/tags/cfg-merge-20023004
/tags/cfg-merge-20023105
/tags/cfg-merger-20011130
/tags/cfo-merge-20050711
/tags/cfo-merge-20051116
/tags/classpath-095-merge-branchpoint
/tags/condexec_merge_20000407
/tags/condexec_merge_20000412
/tags/condexec_merge_20000415
/tags/condexec_merge_20000420
/tags/condexec_merge_20000425
/tags/condexec_merge_20000426
/tags/condexec_merge_20000428
/tags/condexec_merge_20000430
/tags/cp-parser-merge-1
/tags/cp-parser-merge-10
/tags/cp-parser-merge-11
/tags/cp-parser-merge-12
/tags/cp-parser-merge-13
/tags/cp-parser-merge-15
/tags/cp-parser-merge-16
/tags/cp-parser-merge-17
/tags/cp-parser-merge-18
/tags/cp-parser-merge-19
/tags/cp-parser-merge-2
/tags/cp-parser-merge-20
/tags/cp-parser-merge-21
/tags/cp-parser-merge-22
/tags/cp-parser-merge-23
/tags/cp-parser-merge-3
/tags/cp-parser-merge-4
/tags/cp-parser-merge-5
/tags/cp-parser-merge-6
/tags/cp-parser-merge-7
/tags/cp-parser-merge-8
/tags/cp-parser-merge-9
/tags/dataflow-merge-20051019
/tags/dfa-merge_20020423_1
/tags/dfp-mergepoint-20050301
/tags/dfp-mergepoint-20050304
/tags/dfp-mergepoint-20050324
/tags/dfp-mergepoint-20050503
/tags/dfp-mergepoint-20050530
/tags/dfp-mergepoint-20050630
/tags/dfp-mergepoint-20050720
/tags/dfp-mergepoint-20050729
/tags/dfp-mergepoint-20050817
/tags/dfp-mergepoint-20050818
/tags/dfp-mergepoint-20050902
/tags/dfp-mergepoint-20050914
/tags/dfp-mergepoint-20050926
/tags/dfp-mergepoint-20051013
/tags/edge-vector-mergepoint-20040802
/tags/edge-vector-mergepoint-20040810
/tags/edge-vector-mergepoint-20040819
/tags/edge-vector-mergepoint-20040827
/tags/edge-vector-mergepoint-20040829
/tags/edge-vector-mergepoint-20040908
/tags/edge-vector-mergepoint-20040910
/tags/edge-vector-mergepoint-20040918
/tags/egcs_merge_19990218
/tags/ffixinc1204merge
/tags/fortran-experiments-last-merge
/tags/gc_merge_981008
/tags/gc_merge_990327
/tags/gc_merge_990902
/tags/gcc-3_3-e500-merge-20030421
/tags/gcc-3_3-e500-merge-20030904
/tags/gcc-3_4-basic-improvements-merge-20020904
/tags/gcc-3_4-basic-improvements-merge-20020916
/tags/gcc-3_4-basic-improvements-merge-20020917
/tags/gcc-3_4-basic-improvements-merge-20020919
/tags/gcc-3_4-basic-improvements-merge-20020930
/tags/gcc-3_4-basic-improvements-merge-20021013
/tags/gcc-3_4-basic-improvements-merge-20021020
/tags/gcc-3_4-basic-improvements-merge-20021027
/tags/gcc-3_4-basic-improvements-merge-20021105
/tags/gcc-3_4-basic-improvements-merge-20021115
/tags/gcc-3_4-basic-improvements-merge-20021202
/tags/gcj-abi-2-merge-20040514
/tags/gcj-abi-2-merge-20040519
/tags/gcj-abi-2-mergepoint-20041007
/tags/gcj-abi-2-postmerge-20041007
/tags/gcj-abi-2-premerge-20041007
/tags/gcj-abi-2-to-trunk-merge-20041124
/tags/gomp-merge-20050705
/tags/gomp-merge-20050712
/tags/gomp-merge-20050728
/tags/gomp-merge-20050901
/tags/gomp-merge-20050914
/tags/gomp-merge-20050923
/tags/gomp-merge-20051006
/tags/gomp-merge-20051008
/tags/gomp-merge-20051016
/tags/gomp-merge-20051023
/tags/gomp-merge-20051025
/tags/gomp-merge-20051031
/tags/graphite-last-merge
/tags/hammer-3_3-merge-20020702
/tags/hammer-3_3-merge-20020712
/tags/hammer-3_3-merge-20021211
/tags/hammer-3_3-merge-20021412
/tags/hammer-3_3-merge-20021811
/tags/hammer-3_3-merge-20022511
/tags/hammer-3_3-merge-20023112
/tags/hammer-3_3-merge-20030123
/tags/hammer-3_3-merge-20030131
/tags/hammer-3_3-merge-20030201
/tags/hammer-3_3-merge-20030203
/tags/hammer-3_3-merge-20030205
/tags/hammer-3_3-merge-20030212
/tags/hammer-3_3-merge-20030216
/tags/hammer-3_3-merge-20030222
/tags/hammer-3_3-merge-20030226
/tags/hammer-3_3-merge-20030304
/tags/hammer-3_3-merge-20030309
/tags/hammer-3_3-merge-20030318
/tags/hammer-3_3-merge-20030328
/tags/hammer-3_3-merge-20030407
/tags/hammer-3_3-merge-20030411
/tags/hammer-3_3-merge-20030414
/tags/hammer-3_3-merge-20030421
/tags/hammer-3_3-merge-20030611
/tags/hammer-3_3-merge-20030622
/tags/hammer-3_3-merge-20030624
/tags/hammer-3_3-merge-20030703
/tags/hammer-3_3-merge-20031201
/tags/hammer-3_3-merge-20031216
/tags/hammer-3_3-merge-20040114
/tags/hammer-3_3-merge-20040126
/tags/hammer-3_3-merge-20040809
/tags/hammer-merge-20020201
/tags/hammer-merge-20030430
/tags/hammer-merge-20031011
/tags/hammer-merge-20040127
/tags/hammer-merge-20050117
/tags/ifunc-last-merge
/tags/immuse_rewrite-merge-20041008
/tags/improved-aliasing-merge-20050906
/tags/improved-aliasing-merge-20050914
/tags/improved-aliasing-merge-20050921
/tags/improved-aliasing-merge-20050926
/tags/improved-aliasing-merge-20051005
/tags/improved-aliasing-merge-20051018
/tags/ipa-branch-merge-20050903
/tags/ipa-merge-20050915
/tags/itanium_sched_branch_before_merge_251102
/tags/java-gui-20050128-merge-20050214
/tags/java-gui-merge-20040312
/tags/java-gui-merge-20040412
/tags/java-gui-merge-20040526
/tags/java-gui-merge-20040617
/tags/java-gui-merge-20040720
/tags/java-gui-merge-20040831
/tags/java-gui-merge-20041125
/tags/killloop-merge-20050902
/tags/killloop-merge-20051005
/tags/killloop-merge-20051122
/tags/libada-gnattools-merge-20050129
/tags/libada-gnattools-merge-20050211
/tags/libada-gnattools-merge-20050228
/tags/libada-merge-2004-03-31
/tags/libbid-last-merge
/tags/libstdcxx_so_7-merge-20040817
/tags/libstdcxx_so_7-merge-20040824
/tags/libstdcxx_so_7-merge-20040830
/tags/libstdcxx_so_7-merge-20040916
/tags/libstdcxx_so_7-merge-20040924
/tags/libstdcxx_so_7-merge-20041003
/tags/libstdcxx_so_7-merge-20041010
/tags/libstdcxx_so_7-merge-20041018
/tags/libstdcxx_so_7-merge-20041025
/tags/libstdcxx_so_7-merge-20041108
/tags/libstdcxx_so_7-merge-20041116
/tags/libstdcxx_so_7-merge-20041206
/tags/libstdcxx_so_7-merge-20041231
/tags/libstdcxx_so_7-merge-20050109
/tags/libstdcxx_so_7-merge-20050118
/tags/libstdcxx_so_7-merge-20050124
/tags/libstdcxx_so_7-merge-20050130
/tags/libstdcxx_so_7-merge-20050201
/tags/libstdcxx_so_7-merge-20050216
/tags/libstdcxx_so_7-merge-20050221
/tags/libstdcxx_so_7-merge-20050227
/tags/libstdcxx_so_7-merge-20050314
/tags/libstdcxx_so_7-merge-20050322
/tags/libstdcxx_so_7-merge-20050417
/tags/libstdcxx_so_7-merge-20050512
/tags/libstdcxx_so_7-merge-20050522
/tags/libstdcxx_so_7-merge-20050605
/tags/libstdcxx_so_7-merge-20050614
/tags/libstdcxx_so_7-merge-20050630
/tags/libstdcxx_so_7-merge-20050728
/tags/libstdcxx_so_7-merge-20050904
/tags/libstdcxx_so_7-merge-20050918
/tags/libstdcxx_so_7-merge-20051013
/tags/lno-merge-20040120
/tags/lno-merge-20040221
/tags/lno-merge-20040321
/tags/lno-merge-20040425
/tags/lno-merge-20040524
/tags/lno-merge-20040526
/tags/lno-merge-20040612
/tags/lno-merge-20040718
/tags/merge-3_4-csl-sol210-3_4-1
/tags/merge-HEAD-csl-sol210-1
/tags/merge-csl-arm-csl_3_4_3-linux-1
/tags/merge-csl-arm-csl_3_4_3-linux-2
/tags/merge-csl-sol210-3_4-csl-sol210-1
/tags/merge-to-2_95-19990706
/tags/merge-to-csl-arm-1
/tags/merge-to-csl-arm-2
/tags/merge-to-csl-arm-3
/tags/merge-to-csl-arm-4
/tags/merge-to-csl-arm-5
/tags/merged-arm-thumb-backend-branchpoint
/tags/merged-arm-thumb-backend-merge_20000113
/tags/merged-arm-thumb-backend-merge_20000325
/tags/merged-arm-thumb-backend-merge_20000408
/tags/mips-3_4-rewrite-20020619-merge-20020919
/tags/mips-3_4-rewrite-bib-merge-20020924
/tags/mips-3_4-rewrite-bib-merge-20021002
/tags/mips-3_4-rewrite-bib-merge-20021022
/tags/mips-3_4-rewrite-bib-merge-20021105
/tags/mips-3_4-rewrite-bib-merge-20021230
/tags/mips-3_4-rewrite-bib-merge-20030102
/tags/mips-3_4-rewrite-merge-20030127
/tags/new_ia32_final_merge
/tags/new_ia32_merge_990730
/tags/new_ia32_merge_990825
/tags/new_ia32_merge_990828
/tags/new_ia32_merge_990830
/tags/new_ia32_merge_990831
/tags/newppc-branch-mergepoint
/tags/objc-improvements-merge-20030722
/tags/objc-improvements-merge-20030811
/tags/objc-improvements-merge-20030826
/tags/objc-improvements-merge-20030912
/tags/objc-improvements-merge-20030925
/tags/pch-merge-20020211
/tags/pch-merge-20020313
/tags/pch-merge-20020430
/tags/pch-merge-20020517
/tags/pch-merge-20020623
/tags/pch-merge-20020722
/tags/pch-merge-20020809
/tags/pch-merge-20020901
/tags/pch-merge-20020920
/tags/pch-merge-20021108
/tags/pch-merge-20021124
/tags/pch-merge-20021218
/tags/pch-merge-20030102
/tags/post-edge-vector-merge
/tags/pre-big-classpath-merge
/tags/pre-edge-vector-merge
/tags/predcom-last-merge
/tags/premerge-fsf-branchpoint
/tags/ra-merge-20020521
/tags/ra-merge-20020613
/tags/ra-merge-20021120
/tags/ra-merge-20030904
/tags/ra-merge-20031009
/tags/ra-merge-initial
/tags/rtlopt-merge-20020702
/tags/rtlopt-merge-20020712
/tags/rtlopt-merge-20021016
/tags/rtlopt-merge-20021023
/tags/rtlopt-merge-20021412
/tags/rtlopt-merge-20021611
/tags/rtlopt-merge-20021712
/tags/rtlopt-merge-20022511
/tags/rtlopt-merge-20022911
/tags/rtlopt-merge-20023010
/tags/rtlopt-merge-20030123
/tags/rtlopt-merge-20030125
/tags/rtlopt-merge-20030208
/tags/rtlopt-merge-20030212
/tags/rtlopt-merge-20030222
/tags/rtlopt-merge-20030305
/tags/rtlopt-merge-20030318
/tags/rtlopt-merge-20030401
/tags/rtlopt-merge-20030421
/tags/rtlopt-merge-20031101
/tags/sh-elf-3_5-merge-20040613
/tags/sh-elf-3_5-merge-20040620
/tags/sh-elf-3_5-merge-20040628
/tags/sh-elf-4_1-merge-20050706
/tags/sh-elf-4_1-merge-20050718
/tags/sh-elf-4_1-merge-20050913
/tags/simplify-dom-last-merge
/tags/stack-last-merge
/tags/struct-reorg-merge-20041121
/tags/struct-reorg-merge-20050117
/tags/struct-reorg-merge-20050122
/tags/struct-reorg-merge-20050630
/tags/struct-reorg-merge-20080220
/tags/toplevel-bootstrap-merge-20030610
/tags/toplevel-bootstrap-merge-20030612
/tags/toplevel-bootstrap-merge-20030615
/tags/toplevel-bootstrap-merge-20030627
/tags/toplevel-bootstrap-merge-20030901
/tags/tree-ssa-post-merge
/tags/tree-ssa-pre-merge
/tags/var-tracking-assignments-4_3-merge-138264-4_3
/tags/var-tracking-assignments-4_3-merge-138264-after
/tags/var-tracking-assignments-4_3-merge-138264-before
/tags/var-tracking-assignments-4_4-merge-147310-4_4
/tags/var-tracking-assignments-4_4-merge-147310-after
/tags/var-tracking-assignments-4_4-merge-147310-before
/tags/var-tracking-assignments-4_4-merge-148582-4_4
/tags/var-tracking-assignments-4_4-merge-148582-after
/tags/var-tracking-assignments-4_4-merge-148582-before
/tags/var-tracking-assignments-4_4-merge-149247-4_4
/tags/var-tracking-assignments-4_4-merge-149247-after
/tags/var-tracking-assignments-4_4-merge-149247-before
/tags/var-tracking-assignments-4_4-merge-150235-4_4
/tags/var-tracking-assignments-4_4-merge-150235-after
/tags/var-tracking-assignments-4_4-merge-150235-before
/tags/var-tracking-assignments-4_4-merge-150905-4_4
/tags/var-tracking-assignments-4_4-merge-150905-after
/tags/var-tracking-assignments-4_4-merge-150905-before
/tags/var-tracking-assignments-4_4-merge-151281-4_4
/tags/var-tracking-assignments-4_4-merge-151281-after
/tags/var-tracking-assignments-4_4-merge-151281-before
/tags/var-tracking-assignments-4_4-merge-point
/tags/var-tracking-assignments-merge-129153-after
/tags/var-tracking-assignments-merge-129153-before
/tags/var-tracking-assignments-merge-129153-trunk
/tags/var-tracking-assignments-merge-132391-after
/tags/var-tracking-assignments-merge-132391-before
/tags/var-tracking-assignments-merge-132391-trunk-4_3-branchpoint
/tags/var-tracking-assignments-merge-138264-after
/tags/var-tracking-assignments-merge-138264-before
/tags/var-tracking-assignments-merge-138264-trunk
/tags/var-tracking-assignments-merge-141024-after
/tags/var-tracking-assignments-merge-141024-before
/tags/var-tracking-assignments-merge-141024-trunk
/tags/var-tracking-assignments-merge-142635-after
/tags/var-tracking-assignments-merge-142635-before
/tags/var-tracking-assignments-merge-142635-trunk
/tags/var-tracking-assignments-merge-144510-after
/tags/var-tracking-assignments-merge-144510-before
/tags/var-tracking-assignments-merge-144510-trunk
/tags/var-tracking-assignments-merge-145121-after
/tags/var-tracking-assignments-merge-145121-before
/tags/var-tracking-assignments-merge-145121-trunk-4_4-branchpoint
/tags/var-tracking-assignments-merge-147415-after
/tags/var-tracking-assignments-merge-147415-before
/tags/var-tracking-assignments-merge-147415-trunk
/tags/var-tracking-assignments-merge-148582-after
/tags/var-tracking-assignments-merge-148582-before
/tags/var-tracking-assignments-merge-148582-trunk
/tags/var-tracking-assignments-merge-149247-after
/tags/var-tracking-assignments-merge-149247-before
/tags/var-tracking-assignments-merge-149247-trunk
/tags/var-tracking-assignments-merge-150235-after
/tags/var-tracking-assignments-merge-150235-before
/tags/var-tracking-assignments-merge-150235-trunk
/tags/var-tracking-assignments-merge-150905-after
/tags/var-tracking-assignments-merge-150905-before
/tags/var-tracking-assignments-merge-150905-trunk
/tags/var-tracking-assignments-merge-151281-after
/tags/var-tracking-assignments-merge-151281-before
/tags/var-tracking-assignments-merge-151281-trunk-before-vta-merge
/tags/var-tracking-assignments-merge-point
/tags/x86-64-merge-2002-01-14
/tags/x86-64-merge-2002-02-21
/tags/x86-64-merge-2002-03-04
/tags/x86-64-merge-2002-03-18
/tags/x86-64-merge-2002-03-28
/branches/st/tags/merge_from_st_20060905
/branches/st/tags/merge_from_st_20060925
/branches/st/tags/merge_from_st_20061110
/branches/st/tags/merge_from_st_20061123
/branches/st/tags/merge_from_st_20070104
/branches/st/tags/merge_from_st_20070509
/branches/st/tags/merge_from_st_20070710
/tags/apple/after-lno-20040529-merge-to-ppc
/tags/apple/after-lno-20040719-merge-to-ppc
/tags/apple/after-objcp-merge-to-ppc
/tags/apple/before-lno-20040418-merge-to-ppc
/tags/apple/before-lno-20040530-merge-to-ppc
/tags/apple/before-lno-20040719-merge-to-ppc
/tags/apple/before-objcp-merge-to-ppc
/tags/apple/lno-20040418-merge-to-ppc
/tags/apple/local-merge-20050406
/tags/apple/ppc-merge-20040719
/tags/apple/ppc-merge-20040821
/tags/apple/ppc-merge-20040907
/tags/apple/ppc-merge-20041003
/tags/apple/ppc-merge-20041026
/tags/apple/ppc-mergepoint-20040816
/tags/apple/pre-merge-20040818
/tags/ARM/arm-8-branch-merge-point-2019-01-22
/tags/ix86/avx-last-merge
/tags/ix86/gcc-4_3-branch-last-merge
/tags/ix86/gcc-4_4-branch-last-merge
/tags/redhat/4_1-branch-java-last-merge
/tags/redhat/4_1-branch-java-merge-20060823
/tags/redhat/4_1-branch-java-premerge-20070117
/tags/redhat/trunk-java-premerge-20070117

# Snapshot tags (most have been deleted in SVN), including vendor
# snapshots.
# /snapshot/
/tags/gcc-linaro-snapshot-4.9-2015.04
/tags/gcc-linaro-snapshot-4.9-2015.06-1

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > > I'm more worried about missing files. I saw a bunch of those on my
> > > last test.  This could be spurious - the elaborate set of branch
> > > mappings you specified confuses my validation test, because there is
> > > no longer a 1-1 corresponsence between Subversion and git branches.
> > 
> > I'm hoping any such missing file problems come from bugs in the old SVN 
> > dump reader with complicated commits mixing copies / deletions / 
> > replacements with copies from other locations and that your rewrite will 
> > fix the semantics in such cases.
> 
> Also possible.  
> 
> The old code was a hairball. The new code is a bunch of relatively simple
> sequential passes - 10 so far, final version likely to have 12 or 13 - with
> well-defined preconditions and exit contracts. If nothing else this is
> going to make troubleshooting any remaining defects much easier.

I did a comparison of git and SVN checkouts to look at missing file 
problems.  I've now filed reposurgeon issues 171 and 172 for the problems 
I noted.  Issue 171 relates to handling of trunk deletion / recreation.  
Issue 172 relates to the first point where missing file problems appear 
(unless some appeared and then disappeared in the history before then).  
As it's at a very early point in the GCC history (r14877), hopefully it 
shouldn't be too hard to track down if your rewrite doesn't fix it, since 
it shouldn't require loading much of the history to reproduce.  (Roughly, 
it's at the start of EGCS, i.e. around the point where we spliced together 
the gcc2 and EGCS CVS histories when converting from CVS to SVN.  So some 
bits of the history around then may well look weird, but I don't see 
anything particularly odd about that particular SVN commit.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> I did a comparison of git and SVN checkouts to look at missing file 
> problems.  I've now filed reposurgeon issues 171 and 172 for the problems 
> I noted.  Issue 171 relates to handling of trunk deletion / recreation.  
> Issue 172 relates to the first point where missing file problems appear 
> (unless some appeared and then disappeared in the history before then).  
> As it's at a very early point in the GCC history (r14877), hopefully it 
> shouldn't be too hard to track down if your rewrite doesn't fix it, since 
> it shouldn't require loading much of the history to reproduce.  (Roughly, 
> it's at the start of EGCS, i.e. around the point where we spliced together 
> the gcc2 and EGCS CVS histories when converting from CVS to SVN.  So some 
> bits of the history around then may well look weird, but I don't see 
> anything particularly odd about that particular SVN commit.)

Thank you, that is very valuable information to have.

There is probably some odd artifact at the merge point that confuses
my old code.  If we are fortunate, the new code won't be confused.

The old code was brittle and had failures in weird places because I
started on branch analysis and handling of mixed-branch commits too
early.  The new code essentially replays the dump operations into
commits without trying to do branch analysis or mixed-branch
resolution, then does those latter things in separate passes.

We'll know in a day or two, I think. The rewrite is done; I'm
troubleshooting some problems that I *think* are minor but which are
blocking merging to HEAD. 

Once I get the new analyzer passing regressions I'll do a read-limited
conversion up to r14900 and see what's up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Segher Boessenkool]

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.


Segher

Re: Branch and tag deletions

[Joseph Myers]

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
joseph@codesourcery.com

Re: Branch and tag deletions

[Segher Boessenkool]

On Mon, Dec 02, 2019 at 08:37:14PM +0000, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> > 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.

That sounds simpler than it is...  After using this for a while you'll
get names that you want to delete, but that name *already* is in
/refs/deleted.  So what will you name it then?  People will still need
to be able to find it.

But we could make an "old-svn" hierarchy or similar that just has
everything svn has now (and will never change, so it will never cause
conflicts).


Segher

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 00:56, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 08:37:14PM +0000, Joseph Myers wrote:
>> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
>>> 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.
> 
> That sounds simpler than it is...  After using this for a while you'll
> get names that you want to delete, but that name *already* is in
> /refs/deleted.  So what will you name it then?  People will still need
> to be able to find it.
> 
> But we could make an "old-svn" hierarchy or similar that just has
> everything svn has now (and will never change, so it will never cause
> conflicts).
> 
> 
> Segher
> 

Well that's true of /any/ renaming scheme for dead branches.  There's 
nothing special about this one.  On the other hand, there's nothing that 
says that the renamed branch has to have exactly the same name as the 
live one: it's a rename after all.

You only have to run 'svn ls' on the current gcc branches directory in 
SVN to realize just what a mess our current naming scheme it, so I'd 
also suggest that we do some general reorganization of the other 
branches/tags we have, especially if we have a /refs/svn namespace after 
conversion:

a) Only live development branches get moved to the normal git namespace, 
but see d) & e) below
b) vendor branches should move to something like 
refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by 
a normal clone, you'd have to add an explicit map request to see them.
c) user branches should only be in something line 
refs/users/<userid>/{heads/tags} (similar to above)
d) releases should go into refs/{heads/tags}/releases (makes it clearer 
to casual users of the repo that these are 'official')
e) other general development branches in refs/{heads/tags}/devt

That probably means the top-level heads/tags spaces are empty; but I 
have no problem with that.

R.

Re: Branch and tag deletions

[Joseph Myers]

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

Thanks.  Do other people have comments on the list?

I'm going to add one vendor tag that should be uncontroversial to the 
list.  /tags/gcc-1766 is a misnamed Apple tag, and there is already a 
properly named copy with identical contents at /tags/apple/gcc-1766 so 
deleting /tags/gcc-1766 should be safe.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:

> a) Only live development branches get moved to the normal git namespace, but
> see d) & e) below

Where do you suggest dead development branches should go?  (We have 
/branches/dead at present in SVN but hardly anything there; most dead 
development branches are just in /branches.)

> d) releases should go into refs/{heads/tags}/releases (makes it clearer to
> casual users of the repo that these are 'official')

Do you have a particular naming suggestion in there, e.g. 
refs/heads/releases/9 and refs/tags/releases/9.1 (with the ".0" included 
in tag names for old releases to avoid conflict with the branch name), or 
with "gcc" or "branch" etc. in names as at present?

Some of the tags I did not propose deleting are tags for past prereleases 
(we shouldn't need such tags for new -rc versions because a git commit id 
suffices to identify them) and need an appropriate place in git, which 
could also be in refs/tags/releases.  Some are for releases or prereleases 
of subprojects that had such releases on their own (e.g. g77, libgcj, 
libstdc++).  We need to establish where those would go in git.  There are 
also a few miscellaneous tags such as "start" and "first-egcs-checkin".

I can work on a script to do such rearrangements of tags and branches in 
the repository.  My inclination is that such rearrangements of tag and 
branch names are probably done in a separate postprocessing script rather 
than as part of the conversion itself, especially if we're using custom 
namespaces not in refs/heads/ and refs/tags/ - this makes verifying the 
conversion simpler.  (But deletions of tags and branches we don't want to 
convert at all are appropriate to do in SVN.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 15:05, Joseph Myers wrote:
> On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> 
>> a) Only live development branches get moved to the normal git namespace, but
>> see d) & e) below
> 
> Where do you suggest dead development branches should go?  (We have
> /branches/dead at present in SVN but hardly anything there; most dead
> development branches are just in /branches.)

Well, like 'deleted', we could move them out of the normally synced 
namespace; I don't have a strong preference, however, so what would you 
propose?

> 
>> d) releases should go into refs/{heads/tags}/releases (makes it clearer to
>> casual users of the repo that these are 'official')
> 
> Do you have a particular naming suggestion in there, e.g.
> refs/heads/releases/9 and refs/tags/releases/9.1 (with the ".0" included
> in tag names for old releases to avoid conflict with the branch name), or
> with "gcc" or "branch" etc. in names as at present?

I think I'd drop 'release' and use something like releases/gcc-9.1, then 
for the historical egcs releases egcs-<version>.

For the branches, just gcc-9 - I don't see the point in having a 
redundant -branch on the name.

> 
> Some of the tags I did not propose deleting are tags for past prereleases
> (we shouldn't need such tags for new -rc versions because a git commit id
> suffices to identify them) and need an appropriate place in git, which
> could also be in refs/tags/releases.  Some are for releases or prereleases
> of subprojects that had such releases on their own (e.g. g77, libgcj,
> libstdc++).  We need to establish where those would go in git.  There are
> also a few miscellaneous tags such as "start" and "first-egcs-checkin".

We could have another space for rc's alphas, etc, refs/heads/rc would 
work as well as any

> 
> I can work on a script to do such rearrangements of tags and branches in
> the repository.  My inclination is that such rearrangements of tag and
> branch names are probably done in a separate postprocessing script rather
> than as part of the conversion itself, especially if we're using custom
> namespaces not in refs/heads/ and refs/tags/ - this makes verifying the
> conversion simpler.  (But deletions of tags and branches we don't want to
> convert at all are appropriate to do in SVN.)
> 

That would be great.  It would probably also be faster than the 
reposurgeon approach, and it would also work with the other candidate 
conversions we still have on the table.

R.

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 13:26, Joseph Myers wrote:
> 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!)
> 
> Thanks.  Do other people have comments on the list?
> 
> I'm going to add one vendor tag that should be uncontroversial to the
> list.  /tags/gcc-1766 is a misnamed Apple tag, and there is already a
> properly named copy with identical contents at /tags/apple/gcc-1766 so
> deleting /tags/gcc-1766 should be safe.
> 

I've looked through the list; I don't see anything that looks like it 
would be especially controversial.

R.

Re: Branch and tag deletions

[Segher Boessenkool]

On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:56, Segher Boessenkool wrote:
> >That sounds simpler than it is...  After using this for a while you'll
> >get names that you want to delete, but that name *already* is in
> >/refs/deleted.  So what will you name it then?  People will still need
> >to be able to find it.
> >
> >But we could make an "old-svn" hierarchy or similar that just has
> >everything svn has now (and will never change, so it will never cause
> >conflicts).
> 
> Well that's true of /any/ renaming scheme for dead branches.

No, it is not.  If you have a simple "deleted" hierarchy, to which you
add things, you will get conflicts.  If you have one just for things
imported from SVN, it will never change (since SVN is set in stone after
the conversion), and there will not be conflicts.

> There's 
> nothing special about this one.  On the other hand, there's nothing that 
> says that the renamed branch has to have exactly the same name as the 
> live one: it's a rename after all.

Renamed tags and branches are *useless*, we could just as well delete
them completely, if people can no longer find them.

> You only have to run 'svn ls' on the current gcc branches directory in 
> SVN to realize just what a mess our current naming scheme it, so I'd 
> also suggest that we do some general reorganization of the other 
> branches/tags we have, especially if we have a /refs/svn namespace after 
> conversion:
> 
> a) Only live development branches get moved to the normal git namespace, 
> but see d) & e) below

Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
there, and let people make a copy to the "live" stuff if they want it.
And we can pre-populate the things we know are still used, of course, and
all release branches (closed or not), that kind of thing.  But we could
just shovel all that is in SVN into some nice tidy subdir, that normal
people never have to look at again :-)

> b) vendor branches should move to something like 
> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by 
> a normal clone, you'd have to add an explicit map request to see them.
> c) user branches should only be in something line 
> refs/users/<userid>/{heads/tags} (similar to above)

Yup.

> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
> to casual users of the repo that these are 'official')

What are releases?  Release branches?

It would be very inconvenient to not have the recent releases immediately
accessible, fwiw, but those could be just a copy.  And then delete that
one after a branch is closed?

> e) other general development branches in refs/{heads/tags}/devt

What does this mean?  "other", "general"?

> That probably means the top-level heads/tags spaces are empty; but I 
> have no problem with that.

It is good when people get the most often used things immediately.


Segher

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 18:56, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>> That sounds simpler than it is...  After using this for a while you'll
>>> get names that you want to delete, but that name *already* is in
>>> /refs/deleted.  So what will you name it then?  People will still need
>>> to be able to find it.
>>>
>>> But we could make an "old-svn" hierarchy or similar that just has
>>> everything svn has now (and will never change, so it will never cause
>>> conflicts).
>>
>> Well that's true of /any/ renaming scheme for dead branches.
> 
> No, it is not.  If you have a simple "deleted" hierarchy, to which you
> add things, you will get conflicts.  If you have one just for things
> imported from SVN, it will never change (since SVN is set in stone after
> the conversion), and there will not be conflicts.

But you've still got the ongoing branch death issue to deal with, and
that was my point.  If you want to keep them, and you don't want them
polluting the working namespace, you have to do *some* renaming of them.


> 
>> There's 
>> nothing special about this one.  On the other hand, there's nothing that 
>> says that the renamed branch has to have exactly the same name as the 
>> live one: it's a rename after all.
> 
> Renamed tags and branches are *useless*, we could just as well delete
> them completely, if people can no longer find them.

They can be found, it's just that they don't appear in the standard list
since they aren't pulled by default from the upstream repository.  It's
no different from the situation where if you clone from a clone, the
things in the local repository that are in refs/remotes are not pulled
into the secondary clone, unless you add an explicit fetch entry to your
remote's configuration, something like

[origin]
...
	fetch = refs/deleted/*:refs/remotes/origin/deleted/*


So they're not useless as you put it.  They're out of the way, but can
be recovered if there's need.  What's more, if the branch died without
being merged, the blobs for it will stay *on the server* and not waste
users' time and bandwidth by being repeatedly pulled.

> 
>> You only have to run 'svn ls' on the current gcc branches directory in 
>> SVN to realize just what a mess our current naming scheme it, so I'd 
>> also suggest that we do some general reorganization of the other 
>> branches/tags we have, especially if we have a /refs/svn namespace after 
>> conversion:
>>
>> a) Only live development branches get moved to the normal git namespace, 
>> but see d) & e) below
> 
> Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
> there, and let people make a copy to the "live" stuff if they want it.
> And we can pre-populate the things we know are still used, of course, and
> all release branches (closed or not), that kind of thing.  But we could
> just shovel all that is in SVN into some nice tidy subdir, that normal
> people never have to look at again :-)
> 
>> b) vendor branches should move to something like 
>> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by 
>> a normal clone, you'd have to add an explicit map request to see them.
>> c) user branches should only be in something line 
>> refs/users/<userid>/{heads/tags} (similar to above)
> 
> Yup.

And see above for the type of fetch spec you'd need to pull and see them
locally, with the structure I suggest, you can even write

	fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*

and only the ibm sub-part of that hierarchy would be fetched.

> 
>> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
>> to casual users of the repo that these are 'official')
> 
> What are releases?  Release branches?

branches in the heads space, tags in the tags space.

> 
> It would be very inconvenient to not have the recent releases immediately
> accessible, fwiw, but those could be just a copy.  And then delete that
> one after a branch is closed?
> 
>> e) other general development branches in refs/{heads/tags}/devt
> 
> What does this mean?  "other", "general"?

Anything that's not vendor/user specific and not a release - a topic
branch most likely
> 
>> That probably means the top-level heads/tags spaces are empty; but I 
>> have no problem with that.
> 
> It is good when people get the most often used things immediately.

git branch -a will show anything in refs/remotes, and the default pull
spec is to pull refs/heads/* (and anything under that), so all release
and topic branches would be pulled by default, but not anything else.

According to the git fetch manual page, tags are fetched if an object
they point to is fetched.  I presume this only applies to tags under
refs/tags.  But this is getting into details of git that I've not used
before.  I need to experiment a bit more here.

R.

PS.  Just seen https://git-scm.com/docs/gitnamespaces, that might be
exactly what we want for users, vendors and legacy stuff.  I'll
investigate some more...

Re: Branch and tag deletions

[Segher Boessenkool]

On Tue, Dec 03, 2019 at 08:10:37PM +0000, Richard Earnshaw (lists) wrote:
> On 03/12/2019 18:56, Segher Boessenkool wrote:
> > On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
> >>> But we could make an "old-svn" hierarchy or similar that just has
> >>> everything svn has now (and will never change, so it will never cause
> >>> conflicts).
> >>
> >> Well that's true of /any/ renaming scheme for dead branches.
> > 
> > No, it is not.  If you have a simple "deleted" hierarchy, to which you
> > add things, you will get conflicts.  If you have one just for things
> > imported from SVN, it will never change (since SVN is set in stone after
> > the conversion), and there will not be conflicts.
> 
> But you've still got the ongoing branch death issue to deal with, and
> that was my point.  If you want to keep them, and you don't want them
> polluting the working namespace, you have to do *some* renaming of them.

Sure, but how many of those will there be?  This is a different scale
problem from that with the SVN branches and tags, which makes it a quite
different problem.

> >> There's 
> >> nothing special about this one.  On the other hand, there's nothing that 
> >> says that the renamed branch has to have exactly the same name as the 
> >> live one: it's a rename after all.
> > 
> > Renamed tags and branches are *useless*, we could just as well delete
> > them completely, if people can no longer find them.
> 
> They can be found, it's just that they don't appear in the standard list
> since they aren't pulled by default from the upstream repository.  It's
> no different from the situation where if you clone from a clone, the
> things in the local repository that are in refs/remotes are not pulled
> into the secondary clone, unless you add an explicit fetch entry to your
> remote's configuration, something like
> 
> [origin]
> ...
> 	fetch = refs/deleted/*:refs/remotes/origin/deleted/*

No.  If you rename a branch, you have to look at all thousands of branches
to see which one might be the one you wanted.  Something with a similar
name hopefully?

I'm not saying things moved into some separate hierarchy.  That is fine.
But that *will* give conflicts if you keep doing that on a live repo,
and then you *do* need real renames.

And you then cannot refer to things by name anymore.  Which is the common
way we refer to anything.

> >> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
> >> to casual users of the repo that these are 'official')
> > 
> > What are releases?  Release branches?
> 
> branches in the heads space, tags in the tags space.

Release branches and releases are a very different thing.  A release
is some fixed source, like a tarball.  A release branch is a branch, and
what code that is can (and will, and does) change.

Not that I have good suggestions how to make this less confusing.  Well,
maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?

To make it clear that these are "official" the release tags should be
signed with an "official" key, of course ;-)

> > It would be very inconvenient to not have the recent releases immediately
> > accessible, fwiw, but those could be just a copy.  And then delete that
> > one after a branch is closed?
> > 
> >> e) other general development branches in refs/{heads/tags}/devt
> > 
> > What does this mean?  "other", "general"?
> 
> Anything that's not vendor/user specific and not a release - a topic
> branch most likely

Should we often have those?  We can just use user branches for this?

We *want* to rebase etc. on topic branches: allow non-fast-forwards.
And that is *very* problematic if multiple people can write to that
branch.


Segher

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:

> > I can work on a script to do such rearrangements of tags and branches in
> > the repository.  My inclination is that such rearrangements of tag and
> > branch names are probably done in a separate postprocessing script rather
> > than as part of the conversion itself, especially if we're using custom
> > namespaces not in refs/heads/ and refs/tags/ - this makes verifying the
> > conversion simpler.  (But deletions of tags and branches we don't want to
> > convert at all are appropriate to do in SVN.)
> 
> That would be great.  It would probably also be faster than the reposurgeon
> approach, and it would also work with the other candidate conversions we still
> have on the table.

OK, I'm working on that (and have moving of vendor branches working).

Eric, can Richard and I get direct write access to the gcc-conversion 
repository?  Waiting for merge requests to be merged is getting in the way 
of fast iteration on incremental improvements to the conversion machinery, 
it should be possible to get multiple incremental improvements a day into 
the repository.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 03/12/2019 22:43, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 08:10:37PM +0000, Richard Earnshaw (lists) wrote:
>> On 03/12/2019 18:56, Segher Boessenkool wrote:
>>> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>>>>> But we could make an "old-svn" hierarchy or similar that just has
>>>>> everything svn has now (and will never change, so it will never cause
>>>>> conflicts).
>>>>
>>>> Well that's true of /any/ renaming scheme for dead branches.
>>>
>>> No, it is not.  If you have a simple "deleted" hierarchy, to which you
>>> add things, you will get conflicts.  If you have one just for things
>>> imported from SVN, it will never change (since SVN is set in stone after
>>> the conversion), and there will not be conflicts.
>>
>> But you've still got the ongoing branch death issue to deal with, and
>> that was my point.  If you want to keep them, and you don't want them
>> polluting the working namespace, you have to do *some* renaming of them.
> 
> Sure, but how many of those will there be?  This is a different scale
> problem from that with the SVN branches and tags, which makes it a quite
> different problem.

Over time, likely as many, if not more than for svn.  In GIT branch 
development is the norm for most developers.  It's true that most of 
those are private and get serialized before upstreaming (unless we move 
to a different development model, but that's a different discussion), 
but we will likely have at least as many public development branches in 
git as we've ever had in SVN.


> 
>>>> There's
>>>> nothing special about this one.  On the other hand, there's nothing that
>>>> says that the renamed branch has to have exactly the same name as the
>>>> live one: it's a rename after all.
>>>
>>> Renamed tags and branches are *useless*, we could just as well delete
>>> them completely, if people can no longer find them.
>>
>> They can be found, it's just that they don't appear in the standard list
>> since they aren't pulled by default from the upstream repository.  It's
>> no different from the situation where if you clone from a clone, the
>> things in the local repository that are in refs/remotes are not pulled
>> into the secondary clone, unless you add an explicit fetch entry to your
>> remote's configuration, something like
>>
>> [origin]
>> ...
>> 	fetch = refs/deleted/*:refs/remotes/origin/deleted/*
> 
> No.  If you rename a branch, you have to look at all thousands of branches
> to see which one might be the one you wanted.  Something with a similar
> name hopefully?
> 
> I'm not saying things moved into some separate hierarchy.  That is fine.
> But that *will* give conflicts if you keep doing that on a live repo,
> and then you *do* need real renames.
> 
> And you then cannot refer to things by name anymore.  Which is the common
> way we refer to anything.
> 

The problem of naming can be pretty much solved by either putting the 
year name in the branch when its created, so instead of 'fred' you 
create 'fred_2020'.  Now names are unique as long as you don't have two 
in the same year; alternatively, you can add the date as part of the 
renaming process as the branch dies - more likely then it would be the 
year of closure.  Either way, finding them is not hard later on, since 
the prefix part is unchanged.

The other way to solve it is documentation.  We have a web page which is 
*supposed* to list all the development branches we have.  When a branch 
is renamed, the rename can be listed alongside the mark that the branch 
is now dead.

>>>> d) releases should go into refs/{heads/tags}/releases (makes it clearer
>>>> to casual users of the repo that these are 'official')
>>>
>>> What are releases?  Release branches?
>>
>> branches in the heads space, tags in the tags space.
> 
> Release branches and releases are a very different thing.  A release
> is some fixed source, like a tarball.  A release branch is a branch, and
> what code that is can (and will, and does) change.
> 
> Not that I have good suggestions how to make this less confusing.  Well,
> maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?
> 

Branches are branches and appear in the heads name space, tags are tags 
and appear in the tags name space.  There's no way of confusing the two.

Plus, branches leave off the digits that aren't fixed during the life of 
the branch.  And if the branches are called releases/gcc-9 and the tags 
releases/gcc-9.2 (no need for _ anymore, that's an anachronism from the 
CVS days) then there's no ambiguity anyway.

> To make it clear that these are "official" the release tags should be
> signed with an "official" key, of course ;-)

Orthogonal to the git conversion, obviously they need signing; and 
possibly we should restrict ability to move/rename branches in the 
releases space to release managers to avoid accidents.  I don't know if 
that's feasible, but it's quite likely that it is.

> 
>>> It would be very inconvenient to not have the recent releases immediately
>>> accessible, fwiw, but those could be just a copy.  And then delete that
>>> one after a branch is closed?
>>>
>>>> e) other general development branches in refs/{heads/tags}/devt
>>>
>>> What does this mean?  "other", "general"?
>>
>> Anything that's not vendor/user specific and not a release - a topic
>> branch most likely
> 
> Should we often have those?  We can just use user branches for this?
> 

It depends.  Some branches are definitely collaborations, so probably 
want to be more public.  I'm trying not to be prescriptive in this regard.

> We *want* to rebase etc. on topic branches: allow non-fast-forwards.
> And that is *very* problematic if multiple people can write to that
> branch.
> 

Rebasing a publicly visible branch is a no-no.  It causes carnage for 
anyone trying to track it.  But this is straying into development 
workflows again, and that's not for discussion during the conversion 
(feature creep).

R.

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> Eric, can Richard and I get direct write access to the gcc-conversion 
> repository?  Waiting for merge requests to be merged is getting in the way 
> of fast iteration on incremental improvements to the conversion machinery, 
> it should be possible to get multiple incremental improvements a day into 
> the repository.

Sure. I only found one "Richard Earnshaw" and one "Joseph Myers" on Gitlab,
so I have given both Developer access.  I changed thw branch protection rules so
Developers can push.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 4 Dec 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > Eric, can Richard and I get direct write access to the gcc-conversion 
> > repository?  Waiting for merge requests to be merged is getting in the way 
> > of fast iteration on incremental improvements to the conversion machinery, 
> > it should be possible to get multiple incremental improvements a day into 
> > the repository.
> 
> Sure. I only found one "Richard Earnshaw" and one "Joseph Myers" on Gitlab,
> so I have given both Developer access.  I changed thw branch protection rules so
> Developers can push.

Thanks!  I've now merged the outstanding merge requests.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:

> > Thanks.  Do other people have comments on the list?
> > 
> > I'm going to add one vendor tag that should be uncontroversial to the
> > list.  /tags/gcc-1766 is a misnamed Apple tag, and there is already a
> > properly named copy with identical contents at /tags/apple/gcc-1766 so
> > deleting /tags/gcc-1766 should be safe.
> > 
> 
> I've looked through the list; I don't see anything that looks like it would be
> especially controversial.

I've deleted /tags/gcc-1766 as a misnamed and duplicate tag.  I'll plan to 
delete the other 640 tags later today in the absence of objections.  
(It's actually 640 not 645 because 5 tags appear twice in the list as 
having names matching both "merge" and "branchpoint".)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:

> On 03/12/2019 15:05, Joseph Myers wrote:
> > On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> > 
> > > a) Only live development branches get moved to the normal git namespace,
> > > but
> > > see d) & e) below
> > 
> > Where do you suggest dead development branches should go?  (We have
> > /branches/dead at present in SVN but hardly anything there; most dead
> > development branches are just in /branches.)
> 
> Well, like 'deleted', we could move them out of the normally synced namespace;
> I don't have a strong preference, however, so what would you propose?

In my current script (adjust-refs in the gcc-conversion repository; 
limited testing done based on a GCC repository conversion from last week, 
running a fresh conversion now with vendor tags kept for more testing), 
I'm using refs/dead/heads for any branch that's not identified as a 
release branch (those go in refs/heads/releases), is not identified as 
associated with a vendor (those go in refs/vendors/<name>/heads), and has 
not received any commits since the start of December 2017.  The 
development branches that have received commits since then end up in 
refs/heads/devel:

refs/heads/devel/c++-coroutines
refs/heads/devel/c++-modules
refs/heads/devel/c++-name-lookup
refs/heads/devel/gccgo
refs/heads/devel/gfortran-caf
refs/heads/devel/gimple-linterchange
refs/heads/devel/gomp-5_0-branch
refs/heads/devel/ira-select
refs/heads/devel/range-gen3
refs/heads/devel/ranger
refs/heads/devel/ssa-range
refs/heads/devel/unified-autovect

Given the limited number of such active development branches, I suspect 
most people developing on branches are doing so on git-only branches in 
the git mirror because they find git much more convenient for working with 
branches.

I've also added a script add-git-svn-history to the gcc-conversion 
repository, that runs a single git fetch command to make the version of 
history from the old mirror available in refs/git-old/ and 
refs/git-svn-old/ (at a cost of making the repository about 0.3 GB bigger 
on the server).  My expectation for active git-only development branches 
is that the branch maintainer will rebase a copy of the branch onto the 
cleanly converted history and then put that rebased copy in 
refs/heads/devel/, rather than continuing development on the branch in 
refs/git-old/ based on the old version of the history.

(Note for people doing such rebasing: if the branch has had merges to it, 
it's possible that rebasing might go most smoothly if done in two stages: 
first rebase on top of the most recent commit, in the git-svn history, 
from which you've merged, to get rid of the merge commits from the 
history, then rebase on top of the corresponding commit in the new cleanly 
converted history.  It's best to avoid commits from the git-svn version of 
the history ending up in the ancestry of active branches based on the 
clean conversion of the history.)

> > > d) releases should go into refs/{heads/tags}/releases (makes it clearer to
> > > casual users of the repo that these are 'official')
> > 
> > Do you have a particular naming suggestion in there, e.g.
> > refs/heads/releases/9 and refs/tags/releases/9.1 (with the ".0" included
> > in tag names for old releases to avoid conflict with the branch name), or
> > with "gcc" or "branch" etc. in names as at present?
> 
> I think I'd drop 'release' and use something like releases/gcc-9.1, then for
> the historical egcs releases egcs-<version>.

My script also has some such tags g77-*, libf2c-* (it was necessary to 
distinguish very similarly named tags such as g77-0_5_21 and g77_0_5_21, 
where it appeared one tag contained gcc/f/ and the other contained 
libf2c/), libgcj-*.

> For the branches, just gcc-9 - I don't see the point in having a redundant
> -branch on the name.

My script has a special case to use the name 
refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because 
there's also refs/tags/releases/gcc-2.95.2.1, and while technically git 
allows you to have refs/heads/<name> and refs/tags/<name> both present, 
it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" 
would be confusing if you expected it to check out one of the tag and the 
branch and git chose to check out the other.  (Other such ambiguities are 
dealt with by putting ".0" on the names of some tags.)

> > Some of the tags I did not propose deleting are tags for past prereleases
> > (we shouldn't need such tags for new -rc versions because a git commit id
> > suffices to identify them) and need an appropriate place in git, which
> > could also be in refs/tags/releases.  Some are for releases or prereleases
> > of subprojects that had such releases on their own (e.g. g77, libgcj,
> > libstdc++).  We need to establish where those would go in git.  There are
> > also a few miscellaneous tags such as "start" and "first-egcs-checkin".
> 
> We could have another space for rc's alphas, etc, refs/heads/rc would work as
> well as any

For now my script is using refs/tags/prereleases/ (keeping existing choice 
of "pre", "prerelease", "rc", "test" naming rather than making that more 
uniform; refs/tags/prereleases/egcs-1.1.1-pre and 
refs/tags/prereleases/egcs-1.1.1-prerelease are two different tags).

> > I can work on a script to do such rearrangements of tags and branches in
> > the repository.  My inclination is that such rearrangements of tag and
> > branch names are probably done in a separate postprocessing script rather
> > than as part of the conversion itself, especially if we're using custom
> > namespaces not in refs/heads/ and refs/tags/ - this makes verifying the
> > conversion simpler.  (But deletions of tags and branches we don't want to
> > convert at all are appropriate to do in SVN.)
> > 
> 
> That would be great.  It would probably also be faster than the reposurgeon
> approach, and it would also work with the other candidate conversions we still
> have on the table.

My script is checked into the gcc-conversion repository, but the only 
dependency on other machinery in there is that it reads gcc.opts to work 
out the mapping between SVN and git branch names.

My script, by design, *only* renames refs (and prints out the mapping from 
SVN to git ref names, and information about branches that were only found 
in SVN, which could be used in validation of the resulting repository).  
That is, it makes no changes at all to the commit graph (that's left for 
the reposurgeon lift script).  (While the script add-git-svn-history 
*only* adds in the version of history from the git mirror with its own 
commit graph disconnected from that from a fresh conversion, without 
making any changes to the freshly converted history.)

Note that my script to rename refs is not idempotent.  So if experimenting 
with it, you want to copy your converted repository and run it on a copy, 
using a fresh copy for each run of the script.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Segher Boessenkool]

On Wed, Dec 04, 2019 at 06:25:21PM +0000, Joseph Myers wrote:
> In my current script (adjust-refs in the gcc-conversion repository; 
> limited testing done based on a GCC repository conversion from last week, 
> running a fresh conversion now with vendor tags kept for more testing), 
> I'm using refs/dead/heads for any branch that's not identified as a 
> release branch (those go in refs/heads/releases), is not identified as 
> associated with a vendor (those go in refs/vendors/<name>/heads), and has 
> not received any commits since the start of December 2017.  The 
> development branches that have received commits since then end up in 
> refs/heads/devel:
> 
> refs/heads/devel/c++-coroutines
> refs/heads/devel/c++-modules
> refs/heads/devel/c++-name-lookup
> refs/heads/devel/gccgo
> refs/heads/devel/gfortran-caf
> refs/heads/devel/gimple-linterchange
> refs/heads/devel/gomp-5_0-branch
> refs/heads/devel/ira-select
> refs/heads/devel/range-gen3
> refs/heads/devel/ranger
> refs/heads/devel/ssa-range
> refs/heads/devel/unified-autovect
> 
> Given the limited number of such active development branches, I suspect 
> most people developing on branches are doing so on git-only branches in 
> the git mirror because they find git much more convenient for working with 
> branches.

There are only 61 non-user branches on the git mirror, and that includes
the release branches, so just 46 actually (and gccgo is in SVN as well):
  fsf/archer-expr-plugin
  fsf/asan
  fsf/avx2
  fsf/cilkplus
  fsf/cilkplus-4_7-branch
  fsf/cilkplus-4_8-branch
  fsf/cilkplus-merge
  fsf/concepts-cxx2a
  fsf/constexpr
  fsf/cxx-conversion
  fsf/cxx-mem-model
  fsf/fortran-dev
  fsf/gc-improv
  fsf/gcc-4_0-branch
  fsf/gcc-4_1-branch
  fsf/gcc-4_2-branch
  fsf/gcc-4_3-branch
  fsf/gcc-4_4-branch
  fsf/gcc-4_5-branch
  fsf/gcc-4_6-branch
  fsf/gcc-4_7-branch
  fsf/gcc-4_8-branch
  fsf/gcc-4_9-branch
  fsf/gcc-5-branch
  fsf/gcc-6-branch
  fsf/gcc-7-branch
  fsf/gcc-8-branch
  fsf/gcc-9-branch
  fsf/gccgo
  fsf/gccpy
  fsf/gccrs
  fsf/gcn
  fsf/gimple-classes-v2-option-3
  fsf/gimple-front-end
  fsf/gimplefe
  fsf/gomp-nvptx
  fsf/graphite
  fsf/hsa
  fsf/ifunc
  fsf/lw-ipo
  fsf/master
  fsf/melt-branch
  fsf/microblaze
  fsf/modules-ex
  fsf/openacc-gcc-7-branch
  fsf/openacc-gcc-8-branch
  fsf/openacc-gcc-9-branch
  fsf/pph
  fsf/profile-stdlib
  fsf/python
  fsf/reload-v2a
  fsf/split
  fsf/spu-4_5-branch
  fsf/sve
  fsf/transactional-memory
  fsf/trunk
  fsf/type-promotion-pass
  fsf/ubsan
  fsf/vect256
  fsf/vtv
  fsf/x32

(fsf is my namespace for refs from the git mirror:
[remote "fsf"]
        url = git://gcc.gnu.org/git/gcc.git
        fetch = +refs/heads/*:refs/remotes/fsf/*
        fetch = +refs/remotes/*:refs/remotes/svn/*
        prune = true
).

(There are 183 user branches in the git mirror).

> My expectation for active git-only development branches 
> is that the branch maintainer will rebase a copy of the branch onto the 
> cleanly converted history and then put that rebased copy in 
> refs/heads/devel/, rather than continuing development on the branch in 
> refs/git-old/ based on the old version of the history.

We should make everything in git-old read-only.  It is old, it is history,
it should no longer change.

> My script has a special case to use the name 
> refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because 
> there's also refs/tags/releases/gcc-2.95.2.1, and while technically git 
> allows you to have refs/heads/<name> and refs/tags/<name> both present, 
> it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" 
> would be confusing if you expected it to check out one of the tag and the 
> branch and git chose to check out the other.  (Other such ambiguities are 
> dealt with by putting ".0" on the names of some tags.)

And, as I said before, a release branch is a totally different animal
from releases (release tags).  We do this correctly now, let's keep it
that way?


Segher

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 4 Dec 2019, Segher Boessenkool wrote:

> > My script has a special case to use the name 
> > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because 
> > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git 
> > allows you to have refs/heads/<name> and refs/tags/<name> both present, 
> > it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" 
> > would be confusing if you expected it to check out one of the tag and the 
> > branch and git chose to check out the other.  (Other such ambiguities are 
> > dealt with by putting ".0" on the names of some tags.)
> 
> And, as I said before, a release branch is a totally different animal
> from releases (release tags).  We do this correctly now, let's keep it
> that way?

By convention, a branch in SVN lives in /branches and a branch in git 
lives in refs/heads/, whereas a tag in SVN lives in /tags and a tag in git 
lives in refs/tags/.  This doesn't require any particular naming 
convention within those directories, but it's helpful to avoid actually 
having a branch and a tag with the same name.  My script is implementing 
one possible naming convention suggested by Richard (and thus trying to 
make the names of release branches and tags a bit more consistent than 
they are at present).

The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy 
of CVS restrictions on valid names for branches and tags.  Those 
restrictions are not relevant to git or SVN; if picking any new convention 
it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in 
its name rather than "10_1".

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Segher Boessenkool]

On Wed, Dec 04, 2019 at 08:37:17PM +0000, Joseph Myers wrote:
> On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > And, as I said before, a release branch is a totally different animal
> > from releases (release tags).  We do this correctly now, let's keep it
> > that way?
> 
> By convention, a branch in SVN lives in /branches and a branch in git 
> lives in refs/heads/, whereas a tag in SVN lives in /tags and a tag in git 
> lives in refs/tags/.  This doesn't require any particular naming 
> convention within those directories, but it's helpful to avoid actually 
> having a branch and a tag with the same name.

Yes, exactly.  It's inconvenient and confusing in multiple ways to have
the same names for branches and tags.

> The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy 
> of CVS restrictions on valid names for branches and tags.  Those 
> restrictions are not relevant to git or SVN; if picking any new convention 
> it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in 
> its name rather than "10_1".

Avoiding underscores is always welcome :-)


Segher

Re: Branch and tag deletions

[Joseph Myers]

Here is a very preliminary list of refs after postprocessing by my script, 
to indicate what the ref layout would look like.  We can easily change the 
script if we'd like some other layout.  Note that some refs here will go 
away after deleting corresponding tags in SVN, while others are missing 
because of some reposurgeon bugs I'll now report.

refs/dead/heads/BOEHM
refs/dead/heads/C11
refs/dead/heads/C11-atomic
refs/dead/heads/CLASSPATH
refs/dead/heads/CYGNUS
refs/dead/heads/FSF
refs/dead/heads/FastFixinc
refs/dead/heads/NET
refs/dead/heads/Netlib_branch
refs/dead/heads/SGI
refs/dead/heads/addressing-modes
refs/dead/heads/alias-export
refs/dead/heads/alias-improvements
refs/dead/heads/annotalysis
refs/dead/heads/arc-20081210-branch
refs/dead/heads/arc-4_4-20090909-branch
refs/dead/heads/arc-4_4-branch
refs/dead/heads/arc-milepost-branch
refs/dead/heads/asan
refs/dead/heads/ast-optimizer-branch
refs/dead/heads/autovect-branch
refs/dead/heads/avx2
refs/dead/heads/avx512
refs/dead/heads/avx512-vlbwdq
refs/dead/heads/bnw-simple-branch
refs/dead/heads/boehm
refs/dead/heads/boehms-gc
refs/dead/heads/bonzini-4_2-branch-pr32004-reverted
refs/dead/heads/bounded-pointers-branch
refs/dead/heads/c++-compat-branch
refs/dead/heads/c++-concepts
refs/dead/heads/c++-delayed-folding
refs/dead/heads/c-4_5-branch
refs/dead/heads/cell-4_3-branch
refs/dead/heads/cell-4_4-branch
refs/dead/heads/cfg-branch
refs/dead/heads/cfo-branch
refs/dead/heads/cilkplus
refs/dead/heads/cilkplus-4_7-branch
refs/dead/heads/cilkplus-4_8-branch
refs/dead/heads/classpath-generics
refs/dead/heads/clm-micromips
refs/dead/heads/compile-server-branch
refs/dead/heads/conceptgcc-branch
refs/dead/heads/cond-optab
refs/dead/heads/condate
refs/dead/heads/condexec-branch
refs/dead/heads/cp-parser-branch
refs/dead/heads/cp-parser-branch-2
refs/dead/heads/cxx-conversion
refs/dead/heads/cxx-lockfree
refs/dead/heads/cxx-mem-model
refs/dead/heads/cxx-reflection-branch
refs/dead/heads/cxx0x-concepts-branch
refs/dead/heads/cxx0x-lambdas-branch
refs/dead/heads/cygming331
refs/dead/heads/cygming332
refs/dead/heads/cygnus
refs/dead/heads/cygwin-improvements
refs/dead/heads/cygwin-mingw-gcc-3_1-branch
refs/dead/heads/cygwin-mingw-gcc-3_2-branch
refs/dead/heads/cygwin-mingw-gcc-3_2_1-branch
refs/dead/heads/cygwin-mingw-v2-branch
refs/dead/heads/darwin-pic-rewrite
refs/dead/heads/dataflow-branch
refs/dead/heads/debuglocus
refs/dead/heads/devo_gcc_testsuite
refs/dead/heads/dfa-branch
refs/dead/heads/dfp-branch
refs/dead/heads/diagnostics-branch
refs/dead/heads/dwarf4
refs/dead/heads/edge-vector-branch
refs/dead/heads/egcs
refs/dead/heads/egcs_gc_branch
refs/dead/heads/endian-branch
refs/dead/heads/escape-analysis
refs/dead/heads/f_torture
refs/dead/heads/faster-compiler-branch
refs/dead/heads/fe-interface
refs/dead/heads/ffixinc-branch
refs/dead/heads/fixed-point
refs/dead/heads/fixincl-branch
refs/dead/heads/fortran-caf
refs/dead/heads/fortran-dev
refs/dead/heads/fortran-experiments
refs/dead/heads/function-specific-branch
refs/dead/heads/g77-0_6-branch
refs/dead/heads/g77-net-runtime
refs/dead/heads/g77_0_0_21_970811
refs/dead/heads/gc-improv
refs/dead/heads/gcc-3_3-e500-branch
refs/dead/heads/gcc-3_4-basic-improvements-branch
refs/dead/heads/gcc-3_4-e500-branch
refs/dead/heads/gcc-3_5-integration-branch
refs/dead/heads/gcc-4_4-plugins
refs/dead/heads/gcc-in-cxx
refs/dead/heads/gcc-pre-vn
refs/dead/heads/gcc3
refs/dead/heads/gcj-abi-2-dev-branch
refs/dead/heads/gcj-eclipse
refs/dead/heads/gcj-eclipse-jmx
refs/dead/heads/gcj/gcj-abi-experimental-branch
refs/dead/heads/gcj/gcj-abi-stabilization-branch
refs/dead/heads/gcj/gcj-deletion-branch
refs/dead/heads/gcj/gcj-eabi-branch
refs/dead/heads/gcj/gcj-tls-experimental-branch
refs/dead/heads/gcjx-branch
refs/dead/heads/gimple-atomic
refs/dead/heads/gimple-back-end
refs/dead/heads/gimple-front-end
refs/dead/heads/gimple-tuples-branch
refs/dead/heads/glibc-2_0_x
refs/dead/heads/gnu-win32-b20-branch
refs/dead/heads/gomp-20050608-branch
refs/dead/heads/gomp-3_0-branch
refs/dead/heads/gomp-3_1-branch
refs/dead/heads/gomp-4_0-branch
refs/dead/heads/gomp-4_1-branch
refs/dead/heads/gomp-4_5-branch
refs/dead/heads/graphite
refs/dead/heads/gupc
refs/dead/heads/gupc-5-branch
refs/dead/heads/gupc-6-branch
refs/dead/heads/hammer-3_3-branch
refs/dead/heads/hot-cold-branch
refs/dead/heads/hsa
refs/dead/heads/ia64-fp-model-branch
refs/dead/heads/ia64-improvements
refs/dead/heads/ici-20091108-branch
refs/dead/heads/ifunc
refs/dead/heads/immuse-rewrite-branch
refs/dead/heads/improved-aliasing-branch
refs/dead/heads/incremental-compiler
refs/dead/heads/insn-select
refs/dead/heads/ipa-branch
refs/dead/heads/ira
refs/dead/heads/ira-improv
refs/dead/heads/itanium-sched-branch
refs/dead/heads/java-gui-20050128-branch
refs/dead/heads/java-gui-branch
refs/dead/heads/killloop-branch
refs/dead/heads/libada-branch
refs/dead/heads/libada-gnattools-branch
refs/dead/heads/libbid
refs/dead/heads/libgcc-toplevel
refs/dead/heads/libobjc-branch
refs/dead/heads/libobjc_noheaders
refs/dead/heads/libstdcxx-tr2-ideas-branch
refs/dead/heads/libstdcxx_so_7-2-branch
refs/dead/heads/libstdcxx_so_7-branch
refs/dead/heads/lno-branch
refs/dead/heads/loop-nest-optimizer-branch
refs/dead/heads/lra
refs/dead/heads/lto
refs/dead/heads/lto-pressure
refs/dead/heads/lto-streamer
refs/dead/heads/lw-ipo
refs/dead/heads/lw-ipo-4_5
refs/dead/heads/match-and-simplify
refs/dead/heads/meissner-ppc-branch
refs/dead/heads/melt-branch
refs/dead/heads/mem-ref
refs/dead/heads/mem-ref2
refs/dead/heads/mem-ssa
refs/dead/heads/mem-ssa-sigma
refs/dead/heads/microblaze
refs/dead/heads/milepost-20100130-branch
refs/dead/heads/milepost-branch
refs/dead/heads/milepost-integration
refs/dead/heads/mips-3_4-rewrite-branch
refs/dead/heads/miro
refs/dead/heads/mpost-opt-imp-20100127
refs/dead/heads/mpx
refs/dead/heads/multi-target-20100613-branch
refs/dead/heads/multi-target-20100622-branch
refs/dead/heads/multi-target-20100625-branch
refs/dead/heads/multi-target-4_4-branch
refs/dead/heads/named-addr-4_3-branch
refs/dead/heads/named-addr-spaces-branch
refs/dead/heads/new-abi-branch
refs/dead/heads/new-regalloc-branch
refs/dead/heads/new_ia32_branch
refs/dead/heads/newppc-branch
refs/dead/heads/no-undefined-overflow
refs/dead/heads/no_bogosity
refs/dead/heads/objc-improvements-branch
refs/dead/heads/old-autovect-branch
refs/dead/heads/old-pretty-ipa
refs/dead/heads/oldlto
refs/dead/heads/omp-stream
refs/dead/heads/openacc-1_0-branch
refs/dead/heads/opt-diary
refs/dead/heads/out-of-ssa-the-sequel
refs/dead/heads/parloop
refs/dead/heads/pass-activity-log
refs/dead/heads/pch-branch
refs/dead/heads/plugin
refs/dead/heads/plugins
refs/dead/heads/pointer_plus
refs/dead/heads/pph
refs/dead/heads/pr46489-20101217-branch
refs/dead/heads/pr46489-20101227-branch
refs/dead/heads/predcom
refs/dead/heads/pretty-ipa
refs/dead/heads/profile-stdlib
refs/dead/heads/pth-icm
refs/dead/heads/ra-improvements
refs/dead/heads/range-gen
refs/dead/heads/range-gen2
refs/dead/heads/re-arch
refs/dead/heads/re-arch2
refs/dead/heads/reload-branch
refs/dead/heads/reload-v2
refs/dead/heads/reload-v2a
refs/dead/heads/rtl-fud-branch
refs/dead/heads/rtlopt-branch
refs/dead/heads/scalar-storage-order
refs/dead/heads/sched-treegion-branch
refs/dead/heads/sel-sched-branch
refs/dead/heads/sh-elf-3_5-branch
refs/dead/heads/sh-elf-4_1-branch
refs/dead/heads/sh-lra
refs/dead/heads/simplify-dom-branch
refs/dead/heads/split
refs/dead/heads/spu-4_5-branch
refs/dead/heads/ssa-pressure-branch
refs/dead/heads/ssaupdate-branch
refs/dead/heads/stack
refs/dead/heads/static-tree-branch
refs/dead/heads/streamOMP
refs/dead/heads/streamization
refs/dead/heads/stree-branch
refs/dead/heads/struct-reorg-branch
refs/dead/heads/structure-aliasing-branch
refs/dead/heads/subreg-byte-branch
refs/dead/heads/testbranch
refs/dead/heads/thomas-posix1996
refs/dead/heads/thread-annotations
refs/dead/heads/toplevel-bootstrap
refs/dead/heads/tr29124
refs/dead/heads/transactional-memory
refs/dead/heads/tree-cleanup-branch
refs/dead/heads/tree-profiling-branch
refs/dead/heads/tree-serialize-branch
refs/dead/heads/tree-ssa-20020619-branch
refs/dead/heads/tree-ssa-cfg-branch
refs/dead/heads/tree-type
refs/dead/heads/tree-wrapper
refs/dead/heads/ttype
refs/dead/heads/ttype-2015
refs/dead/heads/ttype-2016
refs/dead/heads/ttype-2016-05-03
refs/dead/heads/ttype-2017
refs/dead/heads/ttype-7
refs/dead/heads/ttype-mac
refs/dead/heads/ttype-pro
refs/dead/heads/ttype-pro-trunk
refs/dead/heads/ttype-trial
refs/dead/heads/ttype2
refs/dead/heads/ttype2-trunk
refs/dead/heads/tuples-gomp-3_0-branch
refs/dead/heads/var-mappings-branch
refs/dead/heads/var-template
refs/dead/heads/var-tracking-assignments-4_3-branch
refs/dead/heads/var-tracking-assignments-4_4-branch
refs/dead/heads/var-tracking-assignments-branch
refs/dead/heads/vect256
refs/dead/heads/wide-int
refs/dead/heads/x32
refs/dead/heads/yara-branch
refs/heads/devel/c++-coroutines
refs/heads/devel/c++-modules
refs/heads/devel/c++-name-lookup
refs/heads/devel/gccgo
refs/heads/devel/gfortran-caf
refs/heads/devel/gimple-linterchange
refs/heads/devel/gomp-5_0-branch
refs/heads/devel/ira-select
refs/heads/devel/range-gen3
refs/heads/devel/ranger
refs/heads/devel/ssa-range
refs/heads/devel/unified-autovect
refs/heads/master
refs/heads/releases/egcs-1.0
refs/heads/releases/egcs-1.1
refs/heads/releases/gcc-2.95
refs/heads/releases/gcc-2.95.2.1-branch
refs/heads/releases/gcc-3.0
refs/heads/releases/gcc-3.1
refs/heads/releases/gcc-3.2
refs/heads/releases/gcc-3.3
refs/heads/releases/gcc-3.4
refs/heads/releases/gcc-4.0
refs/heads/releases/gcc-4.1
refs/heads/releases/gcc-4.2
refs/heads/releases/gcc-4.3
refs/heads/releases/gcc-4.4
refs/heads/releases/gcc-4.5
refs/heads/releases/gcc-4.6
refs/heads/releases/gcc-4.7
refs/heads/releases/gcc-4.8
refs/heads/releases/gcc-4.9
refs/heads/releases/gcc-5
refs/heads/releases/gcc-6
refs/heads/releases/gcc-7
refs/heads/releases/gcc-8
refs/heads/releases/gcc-9
refs/heads/releases/libgcj-2.95
refs/tags/misc/GC_4_14
refs/tags/misc/GC_5_0
refs/tags/misc/GC_5_1
refs/tags/misc/GC_6_0
refs/tags/misc/GC_6_3
refs/tags/misc/ZLIB_1_1_3
refs/tags/misc/ZLIB_1_1_4
refs/tags/misc/ZLIB_1_2_1
refs/tags/misc/ZLIB_1_2_3
refs/tags/misc/first-egcs-checkin
refs/tags/misc/gccgo-go1_1_2
refs/tags/misc/gupc_5_2_0_release
refs/tags/misc/last-fsf-checkin
refs/tags/misc/start
refs/tags/prereleases/egcs-1.0.1-prerelease
refs/tags/prereleases/egcs-1.0.2-980309-prerelease
refs/tags/prereleases/egcs-1.0.2-prerelease
refs/tags/prereleases/egcs-1.0.3-prerelease
refs/tags/prereleases/egcs-1.1-prerelease
refs/tags/prereleases/egcs-1.1.1-pre
refs/tags/prereleases/egcs-1.1.1-prerelease
refs/tags/prereleases/egcs-1.1.1-prerelease-2
refs/tags/prereleases/egcs-1.1.1-prerelease-3
refs/tags/prereleases/egcs-1.1.2-prerelease-1
refs/tags/prereleases/egcs-1.1.2-prerelease-2
refs/tags/prereleases/egcs-1.1.2-prerelease-3
refs/tags/prereleases/gcc-2.8
refs/tags/prereleases/gcc-2.95-test
refs/tags/prereleases/gcc-2.95.3-test1
refs/tags/prereleases/gcc-2.95.3-test2
refs/tags/prereleases/gcc-2.95.3-test3
refs/tags/prereleases/gcc-2.95.3-test4
refs/tags/prereleases/gcc-2.95.3-test5
refs/tags/prereleases/gcc-3.2.rhl8.3.2.7
refs/tags/prereleases/gcc-4.2.3-rc1
refs/tags/prereleases/gcc-4.2.4-rc1
refs/tags/prereleases/gcc-4.3.2-rc1
refs/tags/prereleases/libgcj-0.1
refs/tags/prereleases/libstdc++-2.92
refs/tags/prereleases/libstdc++-3.0.95
refs/tags/prereleases/libstdc++-3.0.96
refs/tags/prereleases/libstdc++-3.0.97
refs/tags/releases/egcs-1.0.0
refs/tags/releases/egcs-1.0.1
refs/tags/releases/egcs-1.0.2
refs/tags/releases/egcs-1.0.3
refs/tags/releases/egcs-1.1.0
refs/tags/releases/egcs-1.1.1
refs/tags/releases/egcs-1.1.2
refs/tags/releases/g77-0.5.21
refs/tags/releases/g77-0.5.22
refs/tags/releases/gcc-1766
refs/tags/releases/gcc-2.8.0
refs/tags/releases/gcc-2.8.1
refs/tags/releases/gcc-2.95.0
refs/tags/releases/gcc-2.95.1
refs/tags/releases/gcc-2.95.2
refs/tags/releases/gcc-2.95.2.1
refs/tags/releases/gcc-2.95.3
refs/tags/releases/gcc-3.0.0
refs/tags/releases/gcc-3.0.1
refs/tags/releases/gcc-3.0.2
refs/tags/releases/gcc-3.0.3
refs/tags/releases/gcc-3.0.4
refs/tags/releases/gcc-3.1.0
refs/tags/releases/gcc-3.1.1
refs/tags/releases/gcc-3.2.0
refs/tags/releases/gcc-3.2.1
refs/tags/releases/gcc-3.2.2
refs/tags/releases/gcc-3.2.3
refs/tags/releases/gcc-3.3.0
refs/tags/releases/gcc-3.3.1
refs/tags/releases/gcc-3.3.2
refs/tags/releases/gcc-3.3.3
refs/tags/releases/gcc-3.3.4
refs/tags/releases/gcc-3.3.5
refs/tags/releases/gcc-3.3.6
refs/tags/releases/gcc-3.4.0
refs/tags/releases/gcc-3.4.1
refs/tags/releases/gcc-3.4.2
refs/tags/releases/gcc-3.4.3
refs/tags/releases/gcc-3.4.4
refs/tags/releases/gcc-3.4.5
refs/tags/releases/gcc-3.4.6
refs/tags/releases/gcc-4.0.0
refs/tags/releases/gcc-4.0.1
refs/tags/releases/gcc-4.0.2
refs/tags/releases/gcc-4.0.3
refs/tags/releases/gcc-4.0.4
refs/tags/releases/gcc-4.1.0
refs/tags/releases/gcc-4.1.1
refs/tags/releases/gcc-4.1.2
refs/tags/releases/gcc-4.2.0
refs/tags/releases/gcc-4.2.1
refs/tags/releases/gcc-4.2.2
refs/tags/releases/gcc-4.2.3
refs/tags/releases/gcc-4.2.4
refs/tags/releases/gcc-4.3.0
refs/tags/releases/gcc-4.3.1
refs/tags/releases/gcc-4.3.2
refs/tags/releases/gcc-4.3.3
refs/tags/releases/gcc-4.3.4
refs/tags/releases/gcc-4.3.5
refs/tags/releases/gcc-4.3.6
refs/tags/releases/gcc-4.4.0
refs/tags/releases/gcc-4.4.1
refs/tags/releases/gcc-4.4.2
refs/tags/releases/gcc-4.4.3
refs/tags/releases/gcc-4.4.4
refs/tags/releases/gcc-4.4.5
refs/tags/releases/gcc-4.4.6
refs/tags/releases/gcc-4.4.7
refs/tags/releases/gcc-4.5.0
refs/tags/releases/gcc-4.5.1
refs/tags/releases/gcc-4.5.2
refs/tags/releases/gcc-4.5.3
refs/tags/releases/gcc-4.5.4
refs/tags/releases/gcc-4.6.0
refs/tags/releases/gcc-4.6.1
refs/tags/releases/gcc-4.6.2
refs/tags/releases/gcc-4.6.3
refs/tags/releases/gcc-4.6.4
refs/tags/releases/gcc-4.7.0
refs/tags/releases/gcc-4.7.1
refs/tags/releases/gcc-4.7.2
refs/tags/releases/gcc-4.7.3
refs/tags/releases/gcc-4.7.4
refs/tags/releases/gcc-4.8.0
refs/tags/releases/gcc-4.8.1
refs/tags/releases/gcc-4.8.2
refs/tags/releases/gcc-4.8.3
refs/tags/releases/gcc-4.8.4
refs/tags/releases/gcc-4.8.5
refs/tags/releases/gcc-4.9.0
refs/tags/releases/gcc-4.9.1
refs/tags/releases/gcc-4.9.2
refs/tags/releases/gcc-4.9.3
refs/tags/releases/gcc-4.9.4
refs/tags/releases/gcc-5.1.0
refs/tags/releases/gcc-5.2.0
refs/tags/releases/gcc-5.3.0
refs/tags/releases/gcc-5.4.0
refs/tags/releases/gcc-5.5.0
refs/tags/releases/gcc-6.1.0
refs/tags/releases/gcc-6.2.0
refs/tags/releases/gcc-6.3.0
refs/tags/releases/gcc-6.4.0
refs/tags/releases/gcc-6.5.0
refs/tags/releases/gcc-7.1.0
refs/tags/releases/gcc-7.2.0
refs/tags/releases/gcc-7.3.0
refs/tags/releases/gcc-7.4.0
refs/tags/releases/gcc-7.5.0
refs/tags/releases/gcc-8.1.0
refs/tags/releases/gcc-8.2.0
refs/tags/releases/gcc-8.3.0
refs/tags/releases/gcc-9.1.0
refs/tags/releases/gcc-9.2.0
refs/tags/releases/libf2c-0.5.21
refs/tags/releases/libf2c-0.5.22
refs/tags/releases/libgcj-2.95.0
refs/tags/releases/libgcj-2.95.1
refs/vendors/ARM/heads/aarch64-4.7-branch
refs/vendors/ARM/heads/aarch64-branch
refs/vendors/ARM/heads/arm-8-branch
refs/vendors/ARM/heads/arm-9-branch
refs/vendors/ARM/heads/embedded-4_6-branch
refs/vendors/ARM/heads/embedded-4_7-branch
refs/vendors/ARM/heads/embedded-4_8-branch
refs/vendors/ARM/heads/embedded-4_9-branch
refs/vendors/ARM/heads/embedded-5-branch
refs/vendors/ARM/heads/embedded-6-branch
refs/vendors/ARM/heads/embedded-7-branch
refs/vendors/ARM/heads/hard_vfp_4_4_branch
refs/vendors/ARM/heads/hard_vfp_branch
refs/vendors/ARM/heads/sve-7-branch
refs/vendors/ARM/heads/sve-branch
refs/vendors/ARM/tags/embedded-5-branch-2016q1
refs/vendors/ARM/tags/embedded-5-branch-2016q2
refs/vendors/ARM/tags/embedded-5-branch-2016q3
refs/vendors/ARM/tags/embedded-6-branch-2016q4
refs/vendors/ARM/tags/embedded-6-branch-2017q1-prerelease
refs/vendors/ARM/tags/embedded-6-branch-2017q2
refs/vendors/ARM/tags/embedded-7-branch-2017q4
refs/vendors/ARM/tags/embedded-7-branch-2018q2
refs/vendors/ARM/tags/embedded-8-branch-2018q4
refs/vendors/apple/heads/200508-beta-branch
refs/vendors/apple/heads/200511-release-branch
refs/vendors/apple/heads/200605-release
refs/vendors/apple/heads/gcc_os_35-branch
refs/vendors/apple/heads/local-200502-branch
refs/vendors/apple/heads/ppc-branch
refs/vendors/apple/heads/tiger-release-branch
refs/vendors/apple/heads/trunk
refs/vendors/apple/tags/gcc-1740
refs/vendors/apple/tags/gcc-1741
refs/vendors/apple/tags/gcc-1742
refs/vendors/apple/tags/gcc-1743
refs/vendors/apple/tags/gcc-1744
refs/vendors/apple/tags/gcc-1745
refs/vendors/apple/tags/gcc-1746
refs/vendors/apple/tags/gcc-1747
refs/vendors/apple/tags/gcc-1748
refs/vendors/apple/tags/gcc-1749
refs/vendors/apple/tags/gcc-1750
refs/vendors/apple/tags/gcc-1751
refs/vendors/apple/tags/gcc-1752
refs/vendors/apple/tags/gcc-1753
refs/vendors/apple/tags/gcc-1754
refs/vendors/apple/tags/gcc-1755
refs/vendors/apple/tags/gcc-1756
refs/vendors/apple/tags/gcc-1757
refs/vendors/apple/tags/gcc-1758
refs/vendors/apple/tags/gcc-1759
refs/vendors/apple/tags/gcc-1761
refs/vendors/apple/tags/gcc-1762
refs/vendors/apple/tags/gcc-1763
refs/vendors/apple/tags/gcc-1764
refs/vendors/apple/tags/gcc-1765
refs/vendors/apple/tags/gcc-1766
refs/vendors/apple/tags/gcc-1767
refs/vendors/apple/tags/gcc-1768
refs/vendors/apple/tags/gcc-1769
refs/vendors/apple/tags/gcc-1770
refs/vendors/apple/tags/gcc-1771
refs/vendors/apple/tags/gcc-1772
refs/vendors/apple/tags/gcc-1773
refs/vendors/apple/tags/gcc-1774
refs/vendors/apple/tags/gcc-1775
refs/vendors/apple/tags/gcc-1776
refs/vendors/apple/tags/gcc-1777
refs/vendors/apple/tags/gcc-1778
refs/vendors/apple/tags/gcc-1779
refs/vendors/apple/tags/gcc-1780
refs/vendors/apple/tags/gcc-4000
refs/vendors/apple/tags/gcc-4001
refs/vendors/apple/tags/gcc-4002
refs/vendors/apple/tags/gcc-4003
refs/vendors/apple/tags/gcc-4004
refs/vendors/apple/tags/gcc-4005
refs/vendors/apple/tags/gcc-4006
refs/vendors/apple/tags/gcc-4007
refs/vendors/apple/tags/gcc-4008
refs/vendors/apple/tags/gcc-4009
refs/vendors/apple/tags/gcc-4010
refs/vendors/apple/tags/gcc-4011
refs/vendors/apple/tags/gcc-4012
refs/vendors/apple/tags/gcc-4013
refs/vendors/apple/tags/gcc-4014
refs/vendors/apple/tags/gcc-4015
refs/vendors/apple/tags/gcc-4016
refs/vendors/apple/tags/gcc-4017
refs/vendors/apple/tags/gcc-4018
refs/vendors/apple/tags/gcc-4019
refs/vendors/apple/tags/gcc-4020
refs/vendors/apple/tags/gcc-4021
refs/vendors/apple/tags/gcc-4022
refs/vendors/apple/tags/gcc-4023
refs/vendors/apple/tags/gcc-4024
refs/vendors/apple/tags/gcc-4025
refs/vendors/apple/tags/gcc-4026
refs/vendors/apple/tags/gcc-4027
refs/vendors/apple/tags/gcc-4028
refs/vendors/apple/tags/gcc-4029
refs/vendors/apple/tags/gcc-4030
refs/vendors/apple/tags/gcc-4031
refs/vendors/apple/tags/gcc-4032
refs/vendors/apple/tags/gcc-4033
refs/vendors/apple/tags/gcc-4034
refs/vendors/apple/tags/gcc-4035
refs/vendors/apple/tags/gcc-4036
refs/vendors/apple/tags/gcc-4037
refs/vendors/apple/tags/gcc-4038
refs/vendors/apple/tags/gcc-4039
refs/vendors/apple/tags/gcc-4040
refs/vendors/apple/tags/gcc-4041
refs/vendors/apple/tags/gcc-4042
refs/vendors/apple/tags/gcc-4043
refs/vendors/apple/tags/gcc-4044
refs/vendors/apple/tags/gcc-4045
refs/vendors/apple/tags/gcc-4046
refs/vendors/apple/tags/gcc-4047
refs/vendors/apple/tags/gcc-4048
refs/vendors/apple/tags/gcc-4049
refs/vendors/apple/tags/gcc-4050
refs/vendors/apple/tags/gcc-4051
refs/vendors/apple/tags/gcc-4052
refs/vendors/apple/tags/gcc-4053
refs/vendors/apple/tags/gcc-4054
refs/vendors/apple/tags/gcc-4055
refs/vendors/apple/tags/gcc-4056
refs/vendors/apple/tags/gcc-4057
refs/vendors/apple/tags/gcc-4058
refs/vendors/apple/tags/gcc-4059
refs/vendors/apple/tags/gcc-4060
refs/vendors/apple/tags/gcc-4061
refs/vendors/apple/tags/gcc-4062
refs/vendors/apple/tags/gcc-4200
refs/vendors/apple/tags/gcc-4201
refs/vendors/apple/tags/gcc-5000
refs/vendors/apple/tags/gcc-5001
refs/vendors/apple/tags/gcc-5002
refs/vendors/apple/tags/gcc-5003
refs/vendors/apple/tags/gcc-5004
refs/vendors/apple/tags/gcc-5005
refs/vendors/apple/tags/gcc-5006
refs/vendors/apple/tags/gcc-5007
refs/vendors/apple/tags/gcc-5008
refs/vendors/apple/tags/gcc-5009
refs/vendors/apple/tags/gcc-5010
refs/vendors/apple/tags/gcc-5011
refs/vendors/apple/tags/gcc-5012
refs/vendors/apple/tags/gcc-5013
refs/vendors/apple/tags/gcc-5014
refs/vendors/apple/tags/gcc-5015
refs/vendors/apple/tags/gcc-5016
refs/vendors/apple/tags/gcc-5017
refs/vendors/apple/tags/gcc-5202
refs/vendors/apple/tags/gcc-5203
refs/vendors/apple/tags/gcc-5204
refs/vendors/apple/tags/gcc-5205
refs/vendors/apple/tags/gcc-5206
refs/vendors/apple/tags/gcc-5207
refs/vendors/apple/tags/gcc-5208
refs/vendors/apple/tags/gcc-5209
refs/vendors/apple/tags/gcc-5210
refs/vendors/apple/tags/gcc-5211
refs/vendors/apple/tags/gcc-5212
refs/vendors/apple/tags/gcc-5213
refs/vendors/apple/tags/gcc-5214
refs/vendors/apple/tags/gcc-5215
refs/vendors/apple/tags/gcc-5216
refs/vendors/apple/tags/gcc-5217
refs/vendors/apple/tags/gcc-5218
refs/vendors/apple/tags/gcc-5219
refs/vendors/apple/tags/gcc-5220
refs/vendors/apple/tags/gcc-5221
refs/vendors/apple/tags/gcc-5222
refs/vendors/apple/tags/gcc-5223
refs/vendors/apple/tags/gcc-5224
refs/vendors/apple/tags/gcc-5225
refs/vendors/apple/tags/gcc-5226
refs/vendors/apple/tags/gcc-5227
refs/vendors/apple/tags/gcc-5228
refs/vendors/apple/tags/gcc-5229
refs/vendors/apple/tags/gcc-5230
refs/vendors/apple/tags/gcc-5231
refs/vendors/apple/tags/gcc-5232
refs/vendors/apple/tags/gcc-5233
refs/vendors/apple/tags/gcc-5234
refs/vendors/apple/tags/gcc-5235
refs/vendors/apple/tags/gcc-5236
refs/vendors/apple/tags/gcc-5237
refs/vendors/apple/tags/gcc-5238
refs/vendors/apple/tags/gcc-5239
refs/vendors/apple/tags/gcc-5240
refs/vendors/apple/tags/gcc-5241
refs/vendors/apple/tags/gcc-5242
refs/vendors/apple/tags/gcc-5243
refs/vendors/apple/tags/gcc-5244
refs/vendors/apple/tags/gcc-5245
refs/vendors/apple/tags/gcc-5246
refs/vendors/apple/tags/gcc-5247
refs/vendors/apple/tags/gcc-5248
refs/vendors/apple/tags/gcc-5249
refs/vendors/apple/tags/gcc-5250
refs/vendors/apple/tags/gcc-5251
refs/vendors/apple/tags/gcc-5300
refs/vendors/apple/tags/gcc-5301
refs/vendors/apple/tags/gcc-5302
refs/vendors/apple/tags/gcc-5303
refs/vendors/apple/tags/gcc-5304
refs/vendors/apple/tags/gcc-5305
refs/vendors/apple/tags/gcc-5306
refs/vendors/apple/tags/gcc-5307
refs/vendors/apple/tags/gcc-5308
refs/vendors/apple/tags/gcc-5309
refs/vendors/apple/tags/gcc-5310
refs/vendors/apple/tags/gcc-5311
refs/vendors/apple/tags/gcc-5312
refs/vendors/apple/tags/gcc-5313
refs/vendors/apple/tags/gcc-5314
refs/vendors/apple/tags/gcc-5315
refs/vendors/apple/tags/gcc-5316
refs/vendors/apple/tags/gcc-5317
refs/vendors/apple/tags/gcc-5318
refs/vendors/apple/tags/gcc-5319
refs/vendors/apple/tags/gcc-5320
refs/vendors/apple/tags/gcc-5321
refs/vendors/apple/tags/gcc-5322
refs/vendors/apple/tags/gcc-5323
refs/vendors/apple/tags/gcc-5324
refs/vendors/apple/tags/gcc-5325
refs/vendors/apple/tags/gcc-5326
refs/vendors/apple/tags/gcc-5327
refs/vendors/apple/tags/gcc-5328
refs/vendors/apple/tags/gcc-5329
refs/vendors/apple/tags/gcc-5330
refs/vendors/apple/tags/gcc-5331
refs/vendors/apple/tags/gcc-5332
refs/vendors/apple/tags/gcc-5333
refs/vendors/apple/tags/gcc-5334
refs/vendors/apple/tags/gcc-5335
refs/vendors/apple/tags/gcc-5336
refs/vendors/apple/tags/gcc-5337
refs/vendors/apple/tags/gcc-5338
refs/vendors/apple/tags/gcc-5339
refs/vendors/apple/tags/gcc-5340
refs/vendors/apple/tags/gcc-5341
refs/vendors/apple/tags/gcc-5342
refs/vendors/apple/tags/gcc-5400
refs/vendors/apple/tags/gcc-5401
refs/vendors/apple/tags/gcc-5402
refs/vendors/apple/tags/gcc_os_35-1781
refs/vendors/apple/tags/gcc_os_35-1782
refs/vendors/apple/tags/gcc_os_35-1783
refs/vendors/apple/tags/gcc_os_35-1784
refs/vendors/apple/tags/gcc_os_35-1785
refs/vendors/apple/tags/gcc_os_35-1786
refs/vendors/apple/tags/gcc_os_35-1787
refs/vendors/apple/tags/gcc_os_35-1788
refs/vendors/apple/tags/gcc_os_35-1789
refs/vendors/apple/tags/gcc_os_35-1790
refs/vendors/apple/tags/gcc_os_35-1791
refs/vendors/apple/tags/gcc_os_35-1792
refs/vendors/apple/tags/gcc_os_35-1793
refs/vendors/apple/tags/gcc_os_35-1794
refs/vendors/apple/tags/gcc_os_35-1795
refs/vendors/apple/tags/gcc_os_35-1796
refs/vendors/apple/tags/gcc_os_35-1797
refs/vendors/apple/tags/gcc_os_35-1798
refs/vendors/apple/tags/gcc_os_35-1799
refs/vendors/apple/tags/gcc_os_35-3500
refs/vendors/apple/tags/gcc_os_35-3501
refs/vendors/apple/tags/gcc_os_35-3502
refs/vendors/apple/tags/gcc_os_35-3503
refs/vendors/apple/tags/gcc_os_35-3504
refs/vendors/apple/tags/gcc_os_35-3506
refs/vendors/csl/heads/3_3_1-branch
refs/vendors/csl/heads/3_4-linux-branch
refs/vendors/csl/heads/3_4_0-hp-branch
refs/vendors/csl/heads/3_4_3-linux-branch
refs/vendors/csl/heads/arm-2004-q3-branch
refs/vendors/csl/heads/arm-4_1
refs/vendors/csl/heads/arm-branch
refs/vendors/csl/heads/coldfire-4_1
refs/vendors/csl/heads/gxxpro-3_4-branch
refs/vendors/csl/heads/hpux-branch
refs/vendors/csl/heads/ppc4xx-branch
refs/vendors/csl/heads/sol210-3_4-branch
refs/vendors/csl/heads/sol210-branch
refs/vendors/csl/heads/sourcerygxx-4_1
refs/vendors/csl/heads/wrs-linux-2006q1
refs/vendors/csl/tags/3_3_1-release
refs/vendors/csl/tags/arm-2003-q4
refs/vendors/csl/tags/arm-2004-q1
refs/vendors/csl/tags/arm-2004-q1a
refs/vendors/csl/tags/arm-2004-q3
refs/vendors/csl/tags/arm-2004-q3d
refs/vendors/csl/tags/arm-2005-q1a
refs/vendors/csl/tags/arm-2005-q1b
refs/vendors/csl/tags/arm-2005-q3-1
refs/vendors/csl/tags/arm-2005q3-2
refs/vendors/csl/tags/arm/2006q1-6
refs/vendors/csl/tags/arm/2006q3-19
refs/vendors/csl/tags/arm/2006q3-21
refs/vendors/csl/tags/arm/2006q3-26
refs/vendors/csl/tags/arm/2006q3-27
refs/vendors/csl/tags/coldfire/4.1-10
refs/vendors/csl/tags/coldfire/4.1-11
refs/vendors/csl/tags/coldfire/4.1-28
refs/vendors/csl/tags/coldfire/4.1-30
refs/vendors/csl/tags/coldfire/4.1-32
refs/vendors/csl/tags/gcc-3_3-csl-hp-1
refs/vendors/csl/tags/morpho/4.1-4
refs/vendors/csl/tags/renesas/4.1-6
refs/vendors/csl/tags/renesas/4.1-7
refs/vendors/csl/tags/renesas/4.1-8
refs/vendors/csl/tags/renesas/4.1-9
refs/vendors/csl/tags/sol210-3_4-20050802
refs/vendors/csl/tags/sourcerygxx/3.4.4-17
refs/vendors/csl/tags/sourcerygxx/3.4.4-19
refs/vendors/csl/tags/sourcerygxx/3.4.4-21
refs/vendors/csl/tags/sourcerygxx/3.4.4-25
refs/vendors/csl/tags/sourcerygxx/3.4.4-32
refs/vendors/csl/tags/sourcerygxx/4.1-12
refs/vendors/csl/tags/sourcerygxx/4.1-13
refs/vendors/csl/tags/sourcerygxx/4.1-14
refs/vendors/csl/tags/sourcerygxx/4.1-17
refs/vendors/csl/tags/sourcerygxx/4.1-18
refs/vendors/csl/tags/sourcerygxx/4.1-19
refs/vendors/csl/tags/sourcerygxx/4.1-20
refs/vendors/csl/tags/sourcerygxx/4.1-21
refs/vendors/csl/tags/sourcerygxx/4.1-22
refs/vendors/csl/tags/sourcerygxx/4.1-23
refs/vendors/csl/tags/sourcerygxx/4.1-24
refs/vendors/csl/tags/sourcerygxx/4.1-25
refs/vendors/csl/tags/sourcerygxx/4.1-26
refs/vendors/csl/tags/sourcerygxx/4.1-27
refs/vendors/csl/tags/sourcerygxx/4.1-28
refs/vendors/csl/tags/sourcerygxx/4.1-29
refs/vendors/csl/tags/sourcerygxx/4.1-30
refs/vendors/csl/tags/sourcerygxx/4.1-32
refs/vendors/csl/tags/sourcerygxx/4.1-4
refs/vendors/csl/tags/sourcerygxx/4.1-5
refs/vendors/csl/tags/sourcerygxx/4.1-6
refs/vendors/csl/tags/sourcerygxx/4.1-7
refs/vendors/csl/tags/sourcerygxx/4.1-8
refs/vendors/csl/tags/sourcerygxx/4.1-9
refs/vendors/csl/tags/wrs-linux/3.4.4-20
refs/vendors/csl/tags/wrs-linux/3.4.4-21
refs/vendors/csl/tags/wrs-linux/3.4.4-22
refs/vendors/csl/tags/wrs-linux/3.4.4-23
refs/vendors/csl/tags/wrs-linux/3.4.4-24
refs/vendors/google/heads/gcc-4_6
refs/vendors/google/heads/gcc-4_6-mobile
refs/vendors/google/heads/gcc-4_6-mobile-vtable-security
refs/vendors/google/heads/gcc-4_6_2-mobile
refs/vendors/google/heads/gcc-4_6_3-mobile
refs/vendors/google/heads/gcc-4_7
refs/vendors/google/heads/gcc-4_7-integration
refs/vendors/google/heads/gcc-4_7-mobile
refs/vendors/google/heads/gcc-4_7-mobile-vtable-verification
refs/vendors/google/heads/gcc-4_8
refs/vendors/google/heads/gcc-4_9
refs/vendors/google/heads/gcc-4_9-mobile
refs/vendors/google/heads/integration
refs/vendors/google/heads/main
refs/vendors/ibm/heads/92680e2
refs/vendors/ibm/heads/95282
refs/vendors/ibm/heads/abi-gcc-4_6-branch
refs/vendors/ibm/heads/addr
refs/vendors/ibm/heads/addr2
refs/vendors/ibm/heads/addr3
refs/vendors/ibm/heads/bcp8
refs/vendors/ibm/heads/better-builtin-docs
refs/vendors/ibm/heads/branch4pr89765
refs/vendors/ibm/heads/builtin
refs/vendors/ibm/heads/builtin2
refs/vendors/ibm/heads/bz139777
refs/vendors/ibm/heads/bz78056
refs/vendors/ibm/heads/bz78056-enhance
refs/vendors/ibm/heads/bz80108
refs/vendors/ibm/heads/bz80315
refs/vendors/ibm/heads/constant
refs/vendors/ibm/heads/enhance92680
refs/vendors/ibm/heads/ext-addr
refs/vendors/ibm/heads/gcc-4_1-branch
refs/vendors/ibm/heads/gcc-4_10-ieee
refs/vendors/ibm/heads/gcc-4_3-branch
refs/vendors/ibm/heads/gcc-4_4-branch
refs/vendors/ibm/heads/gcc-4_5-branch
refs/vendors/ibm/heads/gcc-4_6-branch
refs/vendors/ibm/heads/gcc-4_6-prefixes
refs/vendors/ibm/heads/gcc-4_7-branch
refs/vendors/ibm/heads/gcc-4_7-prefixes
refs/vendors/ibm/heads/gcc-4_8-branch
refs/vendors/ibm/heads/gcc-4_8-prefixes
refs/vendors/ibm/heads/gcc-4_9-addr
refs/vendors/ibm/heads/gcc-4_9-branch
refs/vendors/ibm/heads/gcc-4_9-gw
refs/vendors/ibm/heads/gcc-4_9-lra
refs/vendors/ibm/heads/gcc-4_9-prefixes
refs/vendors/ibm/heads/gcc-5-branch
refs/vendors/ibm/heads/gcc-5-ieee
refs/vendors/ibm/heads/gcc-5-prefixes
refs/vendors/ibm/heads/gcc-6-branch
refs/vendors/ibm/heads/gcc-6-complex
refs/vendors/ibm/heads/gcc-7-branch
refs/vendors/ibm/heads/gcc-8-branch
refs/vendors/ibm/heads/gcc-9-branch
refs/vendors/ibm/heads/git280
refs/vendors/ibm/heads/git342
refs/vendors/ibm/heads/git373
refs/vendors/ibm/heads/ieee
refs/vendors/ibm/heads/kelvin-1
refs/vendors/ibm/heads/kelvin-66337
refs/vendors/ibm/heads/kelvin-pr48344
refs/vendors/ibm/heads/kelvin-pr63805
refs/vendors/ibm/heads/kelvin-rfc2463
refs/vendors/ibm/heads/kelvin-rfc2463-restart
refs/vendors/ibm/heads/kelvin-rfc2469
refs/vendors/ibm/heads/kelvin-rfc2496
refs/vendors/ibm/heads/kelvin-rfc2503-restart
refs/vendors/ibm/heads/kelvin-rfc2506
refs/vendors/ibm/heads/lra
refs/vendors/ibm/heads/ltc-139777
refs/vendors/ibm/heads/ltc168854
refs/vendors/ibm/heads/ltc99327
refs/vendors/ibm/heads/meissner-bc8
refs/vendors/ibm/heads/meissner-cmove
refs/vendors/ibm/heads/meissner-vector
refs/vendors/ibm/heads/minmax
refs/vendors/ibm/heads/mtvsrdd
refs/vendors/ibm/heads/pcrel-peter
refs/vendors/ibm/heads/pcrel-trunk
refs/vendors/ibm/heads/power9
refs/vendors/ibm/heads/power9-gcc6
refs/vendors/ibm/heads/pr78303
refs/vendors/ibm/heads/pr90822
refs/vendors/ibm/heads/pre-gcc7
refs/vendors/ibm/heads/restart-rfc2464
refs/vendors/ibm/heads/rfc-2464-bounce2
refs/vendors/ibm/heads/rfc02464
refs/vendors/ibm/heads/rfc2466
refs/vendors/ibm/heads/rfc2467
refs/vendors/ibm/heads/rfc2467.2
refs/vendors/ibm/heads/stage-target
refs/vendors/ibm/heads/stage-test
refs/vendors/ibm/heads/stage-vector
refs/vendors/ibm/heads/switch
refs/vendors/ibm/heads/vctz-candidate
refs/vendors/ix86/heads/atom
refs/vendors/ix86/heads/avx
refs/vendors/ix86/heads/gcc-4_1-branch
refs/vendors/ix86/heads/gcc-4_2-branch
refs/vendors/ix86/heads/gcc-4_3-branch
refs/vendors/ix86/heads/gcc-4_4-branch
refs/vendors/ix86/heads/gcc-4_5-branch
refs/vendors/ix86/tags/gcc-4_1-branch
refs/vendors/ix86/tags/gcc-4_2-branch
refs/vendors/ix86/tags/gcc_4_3_1_release
refs/vendors/linaro/heads/gcc-4_8-branch
refs/vendors/linaro/heads/gcc-4_9-branch
refs/vendors/linaro/tags/gcc-4.8-2013.04
refs/vendors/linaro/tags/gcc-4.8-2013.05
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.06
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.07
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.07-1
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.08
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.09
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.10
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.11
refs/vendors/linaro/tags/gcc-linaro-4.8-2013.12
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.01
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.02
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.03
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.04
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.08
refs/vendors/linaro/tags/gcc-linaro-4.8-2014.11
refs/vendors/linaro/tags/gcc-linaro-4.8-2015.02
refs/vendors/linaro/tags/gcc-linaro-4.8-2015.04
refs/vendors/linaro/tags/gcc-linaro-4.8-2015.06
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.04
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.05
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.06
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.06-1
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.07
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.07-1
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.08
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.09
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.10
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.10-1
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.11
refs/vendors/linaro/tags/gcc-linaro-4.9-2014.12
refs/vendors/linaro/tags/gcc-linaro-4.9-2015.01
refs/vendors/linaro/tags/gcc-linaro-4.9-2015.02
refs/vendors/linaro/tags/gcc-linaro-4.9-2015.03
refs/vendors/linaro/tags/gcc-linaro-4.9-2015.06
refs/vendors/linaro/tags/gcc-linaro-4.9-2017.01
refs/vendors/microblaze/tags/4.1.2
refs/vendors/microblaze/tags/4.2.4
refs/vendors/microblaze/tags/4.3.4
refs/vendors/microblaze/tags/4.4.2
refs/vendors/redhat/heads/fc11-4_4-branch
refs/vendors/redhat/heads/fc5-4_1-branch
refs/vendors/redhat/heads/fc6-4_1-branch
refs/vendors/redhat/heads/gcc-3_2-branch
refs/vendors/redhat/heads/gcc-3_3-branch
refs/vendors/redhat/heads/gcc-3_4-branch
refs/vendors/redhat/heads/gcc-4_0-branch
refs/vendors/redhat/heads/gcc-4_1-branch
refs/vendors/redhat/heads/gcc-4_3-branch
refs/vendors/redhat/heads/gcc-4_4-branch
refs/vendors/redhat/heads/gcc-4_5-branch
refs/vendors/redhat/heads/gcc-4_6-branch
refs/vendors/redhat/heads/gcc-4_7-branch
refs/vendors/redhat/heads/gcc-4_8-branch
refs/vendors/redhat/heads/gcc-4_9-branch
refs/vendors/redhat/heads/gcc-5-branch
refs/vendors/redhat/heads/gcc-6-branch
refs/vendors/redhat/heads/gcc-7-branch
refs/vendors/redhat/heads/gcc-8-branch
refs/vendors/redhat/heads/gcc-9-branch
refs/vendors/redhat/heads/vta-4_4-branch
refs/vendors/redhat/tags/egcs_1_0_x_redhat5_1
refs/vendors/st/heads/README
refs/vendors/st/heads/binutils
refs/vendors/st/heads/cli
refs/vendors/st/heads/cli-be
refs/vendors/st/heads/cli-be-vect
refs/vendors/st/heads/cli-fe
refs/vendors/st/heads/cli-fe-vect
refs/vendors/st/heads/mono-based-binutils
refs/vendors/st/tags/GCC4.3-binutils
refs/vendors/st/tags/GCC4.3-cli-be
refs/vendors/st/tags/GCC4.3-mono-based-binutils
refs/vendors/st/tags/GCC4.4-binutils
refs/vendors/st/tags/GCC4.4-cli-be
refs/vendors/st/tags/GCC4.4-mono-based-binutils
refs/vendors/suse/heads/gcc-4_1-branch
refs/vendors/suse/heads/gcc-4_2-branch
refs/vendors/ubuntu/heads/gcc-4_2-branch
refs/vendors/ubuntu/tags/gcc-4_2_1-release
refs/vendors/ubuntu/tags/gcc-4_2_2-release
refs/vendors/ubuntu/tags/gcc-4_2_3-release
refs/vendors/ubuntu/tags/gcc-4_2_4-release

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Branch and tag deletions

[Maxim Kuvyrkov]

> On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 03/12/2019 18:56, Segher Boessenkool wrote:
>> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>>> That sounds simpler than it is...  After using this for a while you'll
>>>> get names that you want to delete, but that name *already* is in
>>>> /refs/deleted.  So what will you name it then?  People will still need
>>>> to be able to find it.
>>>> 
>>>> But we could make an "old-svn" hierarchy or similar that just has
>>>> everything svn has now (and will never change, so it will never cause
>>>> conflicts).
>>> 
>>> Well that's true of /any/ renaming scheme for dead branches.
>> 
>> No, it is not.  If you have a simple "deleted" hierarchy, to which you
>> add things, you will get conflicts.  If you have one just for things
>> imported from SVN, it will never change (since SVN is set in stone after
>> the conversion), and there will not be conflicts.
> 
> But you've still got the ongoing branch death issue to deal with, and
> that was my point.  If you want to keep them, and you don't want them
> polluting the working namespace, you have to do *some* renaming of them.
> 
> 
>> 
>>> There's 
>>> nothing special about this one.  On the other hand, there's nothing that 
>>> says that the renamed branch has to have exactly the same name as the 
>>> live one: it's a rename after all.
>> 
>> Renamed tags and branches are *useless*, we could just as well delete
>> them completely, if people can no longer find them.
> 
> They can be found, it's just that they don't appear in the standard list
> since they aren't pulled by default from the upstream repository.  It's
> no different from the situation where if you clone from a clone, the
> things in the local repository that are in refs/remotes are not pulled
> into the secondary clone, unless you add an explicit fetch entry to your
> remote's configuration, something like
> 
> [origin]
> ...
> 	fetch = refs/deleted/*:refs/remotes/origin/deleted/*
> 
> 
> So they're not useless as you put it.  They're out of the way, but can
> be recovered if there's need.  What's more, if the branch died without
> being merged, the blobs for it will stay *on the server* and not waste
> users' time and bandwidth by being repeatedly pulled.
> 
>> 
>>> You only have to run 'svn ls' on the current gcc branches directory in 
>>> SVN to realize just what a mess our current naming scheme it, so I'd 
>>> also suggest that we do some general reorganization of the other 
>>> branches/tags we have, especially if we have a /refs/svn namespace after 
>>> conversion:
>>> 
>>> a) Only live development branches get moved to the normal git namespace, 
>>> but see d) & e) below
>> 
>> Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
>> there, and let people make a copy to the "live" stuff if they want it.
>> And we can pre-populate the things we know are still used, of course, and
>> all release branches (closed or not), that kind of thing.  But we could
>> just shovel all that is in SVN into some nice tidy subdir, that normal
>> people never have to look at again :-)
>> 
>>> b) vendor branches should move to something like 
>>> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by 
>>> a normal clone, you'd have to add an explicit map request to see them.
>>> c) user branches should only be in something line 
>>> refs/users/<userid>/{heads/tags} (similar to above)
>> 
>> Yup.
> 
> And see above for the type of fetch spec you'd need to pull and see them
> locally, with the structure I suggest, you can even write
> 
> 	fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*
> 
> and only the ibm sub-part of that hierarchy would be fetched.

IMO, it is valuable to have user and vendor branches under default refs/heads/* hierarchy.  I find it useful to see that IBM's or Arm's branches were updated since I last pulled from upstream.  The fact that branches were updated means that there are development I may want to look at or keep note of.

I feel strongly about vendor branches, and much less strongly about user branches.  Individual users can be less careful in following best git practices, can commit random stuff and rewrite history of their branches.  Therefore, it may make for a smoother git experience to put user branches out of sight.  Vendors, otoh, tend to keep their branches very clean.

> 
>> 
>>> d) releases should go into refs/{heads/tags}/releases (makes it clearer 
>>> to casual users of the repo that these are 'official')
>> 
>> What are releases?  Release branches?
> 
> branches in the heads space, tags in the tags space.
> 
>> 
>> It would be very inconvenient to not have the recent releases immediately
>> accessible, fwiw, but those could be just a copy.  And then delete that
>> one after a branch is closed?
>> 
>>> e) other general development branches in refs/{heads/tags}/devt
>> 
>> What does this mean?  "other", "general"?
> 
> Anything that's not vendor/user specific and not a release - a topic
> branch most likely
>> 
>>> That probably means the top-level heads/tags spaces are empty; but I 
>>> have no problem with that.
>> 
>> It is good when people get the most often used things immediately.
> 
> git branch -a will show anything in refs/remotes, and the default pull
> spec is to pull refs/heads/* (and anything under that), so all release
> and topic branches would be pulled by default, but not anything else.
> 
> According to the git fetch manual page, tags are fetched if an object
> they point to is fetched.  I presume this only applies to tags under
> refs/tags.  But this is getting into details of git that I've not used
> before.  I need to experiment a bit more here.
> 
> R.
> 
> PS.  Just seen https://git-scm.com/docs/gitnamespaces, that might be
> exactly what we want for users, vendors and legacy stuff.  I'll
> investigate some more...

--
Maxim Kuvyrkov
https://www.linaro.org

Re: Branch and tag deletions

[Richard Earnshaw (lists)]

On 05/12/2019 08:55, Maxim Kuvyrkov wrote:
>> On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
>>
>> On 03/12/2019 18:56, Segher Boessenkool wrote:
>>> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>>>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>>>> That sounds simpler than it is...  After using this for a while you'll
>>>>> get names that you want to delete, but that name *already* is in
>>>>> /refs/deleted.  So what will you name it then?  People will still need
>>>>> to be able to find it.
>>>>>
>>>>> But we could make an "old-svn" hierarchy or similar that just has
>>>>> everything svn has now (and will never change, so it will never cause
>>>>> conflicts).
>>>>
>>>> Well that's true of /any/ renaming scheme for dead branches.
>>>
>>> No, it is not.  If you have a simple "deleted" hierarchy, to which you
>>> add things, you will get conflicts.  If you have one just for things
>>> imported from SVN, it will never change (since SVN is set in stone after
>>> the conversion), and there will not be conflicts.
>>
>> But you've still got the ongoing branch death issue to deal with, and
>> that was my point.  If you want to keep them, and you don't want them
>> polluting the working namespace, you have to do *some* renaming of them.
>>
>>
>>>
>>>> There's
>>>> nothing special about this one.  On the other hand, there's nothing that
>>>> says that the renamed branch has to have exactly the same name as the
>>>> live one: it's a rename after all.
>>>
>>> Renamed tags and branches are *useless*, we could just as well delete
>>> them completely, if people can no longer find them.
>>
>> They can be found, it's just that they don't appear in the standard list
>> since they aren't pulled by default from the upstream repository.  It's
>> no different from the situation where if you clone from a clone, the
>> things in the local repository that are in refs/remotes are not pulled
>> into the secondary clone, unless you add an explicit fetch entry to your
>> remote's configuration, something like
>>
>> [origin]
>> ...
>> 	fetch = refs/deleted/*:refs/remotes/origin/deleted/*
>>
>>
>> So they're not useless as you put it.  They're out of the way, but can
>> be recovered if there's need.  What's more, if the branch died without
>> being merged, the blobs for it will stay *on the server* and not waste
>> users' time and bandwidth by being repeatedly pulled.
>>
>>>
>>>> You only have to run 'svn ls' on the current gcc branches directory in
>>>> SVN to realize just what a mess our current naming scheme it, so I'd
>>>> also suggest that we do some general reorganization of the other
>>>> branches/tags we have, especially if we have a /refs/svn namespace after
>>>> conversion:
>>>>
>>>> a) Only live development branches get moved to the normal git namespace,
>>>> but see d) & e) below
>>>
>>> Yes, I called it "old-svn" for a reason.  One idea is to move *everything*
>>> there, and let people make a copy to the "live" stuff if they want it.
>>> And we can pre-populate the things we know are still used, of course, and
>>> all release branches (closed or not), that kind of thing.  But we could
>>> just shovel all that is in SVN into some nice tidy subdir, that normal
>>> people never have to look at again :-)
>>>
>>>> b) vendor branches should move to something like
>>>> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by
>>>> a normal clone, you'd have to add an explicit map request to see them.
>>>> c) user branches should only be in something line
>>>> refs/users/<userid>/{heads/tags} (similar to above)
>>>
>>> Yup.
>>
>> And see above for the type of fetch spec you'd need to pull and see them
>> locally, with the structure I suggest, you can even write
>>
>> 	fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*
>>
>> and only the ibm sub-part of that hierarchy would be fetched.
> 
> IMO, it is valuable to have user and vendor branches under default refs/heads/* hierarchy.  I find it useful to see that IBM's or Arm's branches were updated since I last pulled from upstream.  The fact that branches were updated means that there are development I may want to look at or keep note of.
> 
> I feel strongly about vendor branches, and much less strongly about user branches.  Individual users can be less careful in following best git practices, can commit random stuff and rewrite history of their branches.  Therefore, it may make for a smoother git experience to put user branches out of sight.  Vendors, otoh, tend to keep their branches very clean.
> 


You only need to add fetch lines to your git config and you can see the 
vendor branches as well.  In fact,

	fetch = refs/vendors/*:remotes/origin/vendors/*

is all you need.  Or you can be more specific if you only want a 
specific vendor.

So you can have them, if you want to, but most people, who won't be 
interested will never see them.  If everything goes in the top-level 
name space, then everybody has to deal with them, rather than just those 
who are interested in them.

R.

>>
>>>
>>>> d) releases should go into refs/{heads/tags}/releases (makes it clearer
>>>> to casual users of the repo that these are 'official')
>>>
>>> What are releases?  Release branches?
>>
>> branches in the heads space, tags in the tags space.
>>
>>>
>>> It would be very inconvenient to not have the recent releases immediately
>>> accessible, fwiw, but those could be just a copy.  And then delete that
>>> one after a branch is closed?
>>>
>>>> e) other general development branches in refs/{heads/tags}/devt
>>>
>>> What does this mean?  "other", "general"?
>>
>> Anything that's not vendor/user specific and not a release - a topic
>> branch most likely
>>>
>>>> That probably means the top-level heads/tags spaces are empty; but I
>>>> have no problem with that.
>>>
>>> It is good when people get the most often used things immediately.
>>
>> git branch -a will show anything in refs/remotes, and the default pull
>> spec is to pull refs/heads/* (and anything under that), so all release
>> and topic branches would be pulled by default, but not anything else.
>>
>> According to the git fetch manual page, tags are fetched if an object
>> they point to is fetched.  I presume this only applies to tags under
>> refs/tags.  But this is getting into details of git that I've not used
>> before.  I need to experiment a bit more here.
>>
>> R.
>>
>> PS.  Just seen https://git-scm.com/docs/gitnamespaces, that might be
>> exactly what we want for users, vendors and legacy stuff.  I'll
>> investigate some more...
> 
> --
> Maxim Kuvyrkov
> https://www.linaro.org
> 
> 
> 
> 

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy 
> of CVS restrictions on valid names for branches and tags.  Those 
> restrictions are not relevant to git or SVN; if picking any new convention 
> it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in 
> its name rather than "10_1".

That is correct.  I recommend mapping tags from using "_" to using
".", they're just plain more readable that way.  I have done this in 
previous conversions.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Branch and tag deletions

[Segher Boessenkool]

On Wed, Dec 04, 2019 at 09:53:31AM +0000, Richard Earnshaw (lists) wrote:
> On 03/12/2019 22:43, Segher Boessenkool wrote:
> >>But you've still got the ongoing branch death issue to deal with, and
> >>that was my point.  If you want to keep them, and you don't want them
> >>polluting the working namespace, you have to do *some* renaming of them.
> >
> >Sure, but how many of those will there be?  This is a different scale
> >problem from that with the SVN branches and tags, which makes it a quite
> >different problem.
> 
> Over time, likely as many, if not more than for svn.

How many per year.  How many *random* branches will die each year.

It is my hope that people will *not* put their random WIP stuff in the
global namespace *at all*, ever.  You can put it in a user branch to make
it visible to others, and that is good enough for most purposes.

Such a topic branch will never be merged to trunk in any case!

> In GIT branch 
> development is the norm for most developers.  It's true that most of 
> those are private and get serialized before upstreaming (unless we move 
> to a different development model, but that's a different discussion), 
> but we will likely have at least as many public development branches in 
> git as we've ever had in SVN.

But how many *did* we have in SVN?  And how many were just because we
did not have user branches, and used a more clunky development style?

> The other way to solve it is documentation.  We have a web page which is 
> *supposed* to list all the development branches we have.  When a branch 
> is renamed, the rename can be listed alongside the mark that the branch 
> is now dead.

I still think we should just put everything inherited from SVN into its
own namespace, "old-svn" or whatever.  And make that exactly what is in
SVN now, and don't change it.

This is easiest, and does it have any downsides?

How many branches do we want to keep alive after all development on them
has stopped?  How many did we have in SVN?  As you suggest, we have not
kept track of that well, so the only safe thing to do now is to keep
everything.

> >Release branches and releases are a very different thing.  A release
> >is some fixed source, like a tarball.  A release branch is a branch, and
> >what code that is can (and will, and does) change.
> >
> >Not that I have good suggestions how to make this less confusing.  Well,
> >maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?
> 
> Branches are branches and appear in the heads name space, tags are tags 
> and appear in the tags name space.  There's no way of confusing the two.

git checkout is-this-a-tag-or-a-branch

(I know you can say heads/* and tags/*.  But the point is, it is
confusing to users if you have the same name for two very different
things).

> >>>What does this mean?  "other", "general"?
> >>
> >>Anything that's not vendor/user specific and not a release - a topic
> >>branch most likely
> >
> >Should we often have those?  We can just use user branches for this?
> 
> It depends.  Some branches are definitely collaborations, so probably 
> want to be more public.  I'm trying not to be prescriptive in this regard.
> 
> >We *want* to rebase etc. on topic branches: allow non-fast-forwards.
> >And that is *very* problematic if multiple people can write to that
> >branch.
> 
> Rebasing a publicly visible branch is a no-no.  It causes carnage for 
> anyone trying to track it.  But this is straying into development 
> workflows again, and that's not for discussion during the conversion 
> (feature creep).

Rebasing a per-user branch is explicitly allowed.  It only causes problems
for people who do not *know* it rebases, as well (you need to rebase stuff
that builds on it, too, and you should never merge it -- you shouldn't
anyway, but hey).

It is exactly the same as when you put out new iterations of a patch set
(via email or whatever).


Segher

Re: Branch and tag deletions

[Segher Boessenkool]

On Thu, Dec 05, 2019 at 11:55:12AM +0300, Maxim Kuvyrkov wrote:
> > On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> > And see above for the type of fetch spec you'd need to pull and see them
> > locally, with the structure I suggest, you can even write
> > 
> > 	fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*
> > 
> > and only the ibm sub-part of that hierarchy would be fetched.
> 
> IMO, it is valuable to have user and vendor branches under default refs/heads/* hierarchy.  I find it useful to see that IBM's or Arm's branches were updated since I last pulled from upstream.  The fact that branches were updated means that there are development I may want to look at or keep note of.

Yes.  And while that can be configured, that has to be done every time
someone makes a new clone.  And inevitably people will screw this up,
and inevitably it causes more problems than it helps when people have
different configurations for this.

> I feel strongly about vendor branches, and much less strongly about user branches.  Individual users can be less careful in following best git practices, can commit random stuff and rewrite history of their branches.

Absolutely.  This should be encouraged even, imo: people should make
their "feature" branches contain exactly what they intend to commit.


Segher