Hi Junio, On 09/10/2022 13:07, Junio C Hamano wrote: > 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 ;-) > Thanks for the clarification. My confusion about `maint` started quite a few years back and may be a mixture of a number of different issues, or simply my misunderstanding. I'm guessing here, but it may have been, that back then, that the maint branch was a link to the relevant maint-xx, rather than a 'symref' and that at that time the Git-for-Windows didn't really handle them, so `maint` may not have shown for me (similar to how RelNotes is configured in the Git repo). It may also have been early confusion about remotes and their branches, and the impression that I needed (or should expect) a local branch of the same name and this wasn't happening (obvious in retrospect), so I never found any `maint` in my repo. The whole 'remote tracking branches' stuff took a long time to understand and was non-obvious from my perspective. I suspect many newbies have similar issues (e.g. the current thread https://lore.kernel.org/git/DU2P194MB15841850A17436C7AE34C149E3239@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#t) -- Philip
