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
