What is the justification for the practice?
GitHub doesn’t charge for the repository space and bare zero-depth cloning solves the checkout issue.
Can you explain more clearly what you mean?
I am not really involved in CPython development but I do follow it and I have read your question but have no idea what you are referring to.
I’m not aware of any tags being deleted; we even have tag protection enabled to prevent anyone from doing so. Could you explain where you’re seeing that, sorry?
As for branches, the RMs convert obsolete upstream release branches after they are EOL and will never be developed further to a protected tag of the same name pointing to the tip of the branch for posterity. A Git tag losslessly preserves the branch exactly as it last was (and essentially boils down to exactly the same thing as one—a named pointer to a commit, with the bonus of some extra metadata), while being (quasi-)immutable as is naturally desired; the only difference is that it is not directly usable for further active development (though it is trivial for you to create a branch from the tag, if you need it).
This avoids keeping around an ever-growing list of avoid keeping around old branches that will never be developed or modified further (which is the purpose of a branch vs a tag), which takes up ever-increasing space in the CLI and UI for no benefit, and avoids the possibility of accidentally selecting, targeting or modifying an EOL branch.
4 Likes
Thanks for the detailed explanation.
In re deleted tags, I had to pull the tags to see the missing ones, so that’s on me.
Also thanks for describing the branch-to-tag conversion (i.e. 3.7) - I wasn’t aware of it being done.
That said, GitHub deals with stale branches by making them “stale”, i.e. they eventually disappear from the displayed lists and you are required to make additional clicks to see them if you do so desire. That is to say stale branches don’t actually bother people as you don’t see them unless you want to.
On the automation side, though, the disappearing branches complicate things as now I have to have two mechanism to get the latest commit for a specific version of Python depending on whether it is stale or not.
That’s true, though I’m not sure there’s a compelling reason to wait around for this to happen, and still show up for people using other interfaces than GitHub. It also means the branch protection rules and certain other tooling have to stick around forever, too.
It shouldn’t, though? git rev-list -n 1 $VERSION, where version $VERSION is e.g. 3.7, 3.8, etc. (the name of the branch/tag) will return the latest commit regardless of whether the particular version is a branch or a tag, and most Git commands that accept one accept the other. Fundamentally, a branch or a tag boils down to the same basic thing—a ref (i.e. pointer) to a certain commit.
On GitHub, so long as the name is the same, GitHub URLs (and most queries, etc) should work exactly as before, as they don’t distinguish between branches and tags.
2 Likes
It shouldn’t or should depending on what you’re doing. 
Find the latest tagged commit in a branch, for example, requires a branch.
Checkouts of tags are also headless, which may or may not be relevant depending on what is being done.
Those are corner cases but depending on the levels of automation.
True, but should only be relevant if you’re going to development on that branch, which you shouldn’t be for outdated branches - or if you are, the extra hassle of “make a new branch starting at this tag” is a good reminder that what you’re doing is unusual. If all you want to do is “build CPython 3.9”, it should make no difference whether that’s a branch or a tag.
5 Likes
The policy of converting EOL branches to tags is documented in PEP 101:
1 Like