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
