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
Attachment:
signature.asc
Description: PGP signature
