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

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

Re: Branch and tag deletions

On 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


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