On 2021-04-24 at 00:22:06, Antoine Beaupré wrote:
> For local branches, that doesn't matter much: no "links" should point
> there. But git repos are, nowadays, living web sites on web servers like
> GitHub, GitLab, cgit, or whatever. You have no way of telling those
> sites "I am renaming a branch", so they don't have an opportunity of
> fixing broken links (and, incidentally, bypassing branch protection,
> although I actually use the GitLab API to workaround that problem).
> 
> So I wonder: could git remote branch renames as an operation on remotes?
> How would that look? Is that something that the git project should work
> on? Or is this something strictly reserved to the API space of git
> forges? In that case, how do I tell my gitolite server that it's okay
> to rename a branch since it doesn't have an API? :)

I think the ability to rename a branch, and to update the HEAD reference
(and other symrefs) would be a nice protocol extension to add.  I've
considered doing this in the past, but have never gotten around to it.
It's definitely a feature I'd like to see.

> Or, maybe, should this script be sent as a [PATCH] instead and just be
> merged into git itself? Maybe in contrib/? I do see some Python in
> there, so I don't feel too much like an heretic... Obviously, it could
> be rewritten in C, but it would feel such a pain in the back to me... I
> already rewrote it from this shell script, which is still available
> here:

In general, Git tries to remain neutral on forges and therefore we're
probably not super likely to adopt tooling that's specific to a set of
forges.  I do, of course, think this script has utility and serves a
particular need for users, even though it's not likely that Git will
host it itself.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US