All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Antoine Beaupré" <anarcat@debian.org>
Cc: git@vger.kernel.org
Subject: Re: how to rename remote branches, the long way
Date: Sat, 24 Apr 2021 17:38:02 +0000	[thread overview]
Message-ID: <YIRXem9ApAsqgl6D@camp.crustytoothpaste.net> (raw)
In-Reply-To: <87mttofs5t.fsf@angela.anarc.at>

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-04-24 17:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-24  0:22 how to rename remote branches, the long way Antoine Beaupré
2021-04-24  1:08 ` Felipe Contreras
2021-04-24  1:12   ` Antoine Beaupré
2021-04-24  3:44     ` Felipe Contreras
2021-04-24 15:05       ` Antoine Beaupré
2021-04-29  0:23         ` Felipe Contreras
2021-04-24 18:24       ` brian m. carlson
2021-04-29  0:28         ` Felipe Contreras
2021-04-24 17:38 ` brian m. carlson [this message]
2021-04-24 18:03   ` Antoine Beaupré

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YIRXem9ApAsqgl6D@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=anarcat@debian.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.