Re: [PATCH v2] symbolic-ref: teach "--[no-]recurse" option

[Junio C Hamano <gitster@pobox.com>]

Philip Oakley <philipoakley@iee.email> writes:

> Is there also a need to update SubmittingPatches to clarify the
> distinctions between the generic name 'maint', the specific `maint-xx`
> branches, and the symbolic ref linkages from `maint`.

Not at all.  Perhaps you are thinking about MaintNotes, but even
there, general public do not have to be concerned about maint-xx
most of the time.  I myself would not be keeping branches for
ancient maintenance tracks anywhere.  As the older maintenance
tracks, other than the most recent ones, do not get topics graduated
to 'master' merged down by me (even though topic branches that fix
notable bugs may fork from an older version to allow motivated third
party maintainers to merge them down to older maintenance releases),
there is not really a reason to keep branches like maint-2.15 for
daily operation.  Only when we need security updates that go back to
older maintenance tracks, I may do

    $ git checkout -b maint-2.30 v2.30.5
    $ git merge cve-something-fix
    ... edit release notes etc. ...
    $ git commit -m 'Git 2.30.6'
    $ git tag -s -m 'Git 2.30.6' v2.30.6

but after that is done, there is no reason to keep an old branch
like maint-2.30 lying around, other than to make it easier to
prepare for v2.30.7 (as maint-2.30 will remember what tag was the
latest on that particular maintenance track).

> The descriptions give the impression there is just a single main branch,
> with a singular name, and that was the end of it.

And that is the correct world view for most of the  general public.

    https://github.com/git/git/

shows 'maint', 'master' ('main'), 'next', and 'seen' from the
project code, plus 'todo' which holds an unrelated history that
keeps track of maintenance tools and misc stuff.

By the way, I do not personally have 'main' in my working
repository.  The only trick I have to help folks who expect to see
'main' instead of 'master' is the push refspec to distribute the
integration results to various repositories.  My 'master' is pushed
to both 'master' and 'main' in destination repositories.

The mirror/backup repository of my private working repository does
have tentive branches, like the broken-out topic branches that are
still active, which are pruned when they no longer are needed.
Some maint-xx branches are also there but they are there not because
they are necessary but because I just haven't bothered to clean them
up ;-)