{"thread":{"id":"55550","subject":"how to rename remote branches, the long way","startedAt":"2021-04-24T00:30:50Z","lastAt":"2021-04-29T00:28:54Z","messageCount":10,"participants":["Antoine Beaupré","Felipe Contreras","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422841","messageId":"87mttofs5t.fsf@angela.anarc.at","threadId":"55550","inReplyTo":null,"subject":"how to rename remote branches, the long way","fromName":"Antoine Beaupré","fromEmail":"anarcat@debian.org","sentAt":"2021-04-24T00:22:06Z","receivedAt":"2021-04-24T00:30:50Z","isPatch":false,"sender":{"key":"anarcat@debian.org","avatar":"https://avatars.githubusercontent.com/u/796623?v=4"},"body":"So this is a rather long story, which I plan to expand on in a blog post\nwhen I find the time, but to make that story short:\n\nI wrote a Python script to rename branches in git.\n\nBefore people start throwing things (like `git push origin oldref:newref\n:oldref`) at me, consider that I've been beating my head against this\nfor a while, and everywhere I look basically suggests this:\n\n    git branch -m to_branch\n    git push origin from_branch:to_branch :from_branch\n\nNow, to be fair, the latter is an optimization I found only after\nsearching more deeply for the problem (of course, on SO):\n\nhttps://stackoverflow.com/a/21302474\n\nBut while the above look fine to a Stackoverflow user, a more experience\ngit user might know it has multiple problems:\n\n 1. it will fail if you try to rename the master branch, or any\n    branch protected by hooks on (say) GitHub or GitLab (because you\n    can't delete a default or protected branch)\n 2. it will not update the remote default branch (AKA the remote HEAD)\n 3. it will not update the local HEAD pointer for the remote branch\n    (noticeable on a `git remote prune origin`)\n 4. it will break all links to from_branch on the remote (e.g. on gitweb\n    and so on)\n\nI made a script which fixes all those problems except the last one (and\nonly for GitLab, for problem 1). I am kind of hoping I didn't waste my\ntime doing so, but I would still be happy to be proven wrong and be\nshown an easier way.\n\nThis is the script:\n\nhttps://gitlab.com/anarcat/scripts/-/blob/main/git-branch-rename-remote\n\nRaw/javascript-less version:\n\nhttps://gitlab.com/anarcat/scripts/-/raw/main/git-branch-rename-remote\n\nAlso attached at the end of this email.\n\nNow, I send this in a gesture of good will and spirit of sharing. I\nwould of course be happy to take contributions, in the form of merge\nrequests on GitLab or patches by email, as you see fit.\n\nI wrote this primarily with the \"master to main\" migration, because a\nbunch of projects (including mine) are suddenly, actually migrating\ntheir main branch from master to main. Personnally, it's because I'm\ntired of being yelled \"master\" from my shell prompt all the time, but\nnaturally, I guess opinions on the matter vary. The script, of course,\nworks with any combination of branch names and remotes -- heck, you can\neven rename back from master to main if that's your kink -- but the\ndefaults are to cover for the \"main\" migration.\n\nBut this also makes me wonder if we there ever was a wider discussion on\n(remote) branch renames as a primary operation. It seems like git\ndoesn't really support branch renames right now. `git branch --move`\n*looks* like a rename, but really, it's probably just laying down a new\nref and deleting the old one (I haven't actually looked). With remotes,\nanyways, that's certainly the only story there is.\n\nFor local branches, that doesn't matter much: no \"links\" should point\nthere. But git repos are, nowadays, living web sites on web servers like\nGitHub, GitLab, cgit, or whatever. You have no way of telling those\nsites \"I am renaming a branch\", so they don't have an opportunity of\nfixing broken links (and, incidentally, bypassing branch protection,\nalthough I actually use the GitLab API to workaround that problem).\n\nSo I wonder: could git remote branch renames as an operation on remotes?\nHow would that look? Is that something that the git project should work\non? Or is this something strictly reserved to the API space of git\nforges? In that case, how do I tell my gitolite server that it's okay\nto rename a branch since it doesn't have an API? :)\n\nOr, maybe, should this script be sent as a [PATCH] instead and just be\nmerged into git itself? Maybe in contrib/? I do see some Python in\nthere, so I don't feel too much like an heretic... Obviously, it could\nbe rewritten in C, but it would feel such a pain in the back to me... I\nalready rewrote it from this shell script, which is still available\nhere:\n\nhttps://gitlab.com/anarcat/scripts/-/blob/2bd01ae584994b8160b1dff20f3e290ace23265c/git-rename-to-main\n\nSo many questions, I hope I don't make a fool of myself here, and thanks\nin advance for your time.\n\nA.\n\n-- \nImagination is more important than knowledge.\nKnowledge is limited.\nImagination encircles the world.\n                        - Albert Einstein\n\n\n#!/usr/bin/python3\n\n\"\"\"Rename a branch locally and, as much as possible, remotely. This\nwas designed to help with the master/main transition, but can be used\nwith any branch name combination.\"\"\"\n\nimport argparse\nimport logging\nimport os\nimport re\nfrom subprocess import run, check_call, check_output, CalledProcessError, DEVNULL\n\nimport gitlab\n\n\ndef main():\n    logging.basicConfig(format=\"%(levelname)s: %(message)s\", level=\"INFO\")\n    args = RenamerArgumentParser().parse_args()\n    if args.quiet:\n        git_output = DEVNULL\n    else:\n        # None actually means \"normal\", ie. stdout\n        git_output = None\n    try:\n        check_output((\"git\", \"show-ref\", \"refs/heads/%s\" % args.from_branch))\n    except CalledProcessError:\n        logging.warning(\n            \"branch %s does not exist, assuming already renamed\", args.from_branch\n        )\n    else:\n        logging.info(\"renaming %s to %s\", args.from_branch, args.to_branch)\n        check_call(\n            (\"git\", \"branch\", \"--move\", args.from_branch, args.to_branch),\n            stdout=git_output,\n        )\n\n    logging.info(\"fetching remote %s to see if it needs a rename\", args.remote)\n    check_call((\"git\", \"fetch\", args.remote), stdout=git_output)\n\n    logging.info(\"reseting %s/HEAD to %s unconditionnally\", args.remote, args.to_branch)\n    check_call(\n        (\n            \"git\",\n            \"symbolic-ref\",\n            f\"refs/remotes/{args.remote}/HEAD\",\n            f\"refs/remotes/{args.remote}/{args.to_branch}\",\n        ),\n        stdout=git_output,\n    )\n\n    logging.info(\n        \"setting local branch to follow %s/%s unconditionnally\",\n        args.remote,\n        args.to_branch,\n    )\n    if (\n        run(\n            (\"git\", \"branch\", \"-u\", f\"{args.remote}/{args.to_branch}\"),\n            stdout=DEVNULL if args.quiet else None,\n        ).returncode\n        == 0\n    ):\n        logging.info(\n            \"remote branch %s/%s already exists, all done\", args.remote, args.to_branch\n        )\n        return\n\n    logging.info(\"remote branch %s not found, pushing new branch\", args.to_branch)\n    check_call((\"git\", \"push\", \"-u\", args.remote, args.to_branch), stdout=git_output)\n\n    remote_ssh, remote_url_http, forge_url, project = guess_remote_urls(args.remote)\n    if \"@\" in remote_ssh:\n        ssh_cmd = (\"ssh\", remote_ssh, f\"git symbolic-ref HEAD {args.to_branch}\")\n        logging.info(\n            \"SSH remote detected, trying to fix default branch with: %s\", ssh_cmd\n        )\n        if run(ssh_cmd, stdout=git_output).returncode != 0:\n            logging.warning(\"failed to change HEAD on remote with SSH\")\n\n    logging.info(\"trying to delete old branch %s from remote\", args.from_branch)\n    if (\n        not run(\n            (\"git\", \"push\", \"-d\", args.remote, args.from_branch), stdout=git_output\n        ).returncode\n        == 0\n    ):\n        logging.warning(\"push denied by remote, maybe a branch protected in GitLab?\")\n        # TODO: GitHub support\n        gitlab_branch_change_default(\n            forge_url, project, args.from_branch, args.to_branch\n        )\n        logging.info(\n            \"trying to delete old branch %s from remote, again\", args.from_branch\n        )\n        check_call(\n            (\"git\", \"push\", \"-d\", args.remote, args.from_branch), stdout=git_output\n        )\n    logging.info(\n        \"all done, branch %s renamed to %s locally and on remote %s\",\n        args.from_branch,\n        args.to_branch,\n        args.remote,\n    )\n\n\ndef gitlab_branch_change_default(forge_url, project, from_branch, to_branch):\n    \"\"\"wrapper around the branch default change\n\n    Just changing the default is not enough: we also want to apply the\n    same protections as the previous branch to the new branch.\n    \"\"\"\n    private_token = os.environ.get(\"GITLAB_PRIVATE_TOKEN\", None)\n    if private_token is None:\n        logging.error(\n            \"cannot talk to the GitLab forge without the GITLAB_PRIVATE_TOKEN environment variable\"\n        )\n        return\n\n    gl = gitlab.Gitlab(forge_url, private_token=private_token)\n    gl_project = gl.projects.get(project)\n\n    logging.info(\"protecting new branch %s\", to_branch)\n    gl_project.branches.get(to_branch).protect()\n    logging.info(\"unprotecting old branch %s\", from_branch)\n    gl_project.branches.get(from_branch).unprotect()\n\n    logging.info(\"changing default branch to %s\", to_branch)\n    gl_project.default_branch = to_branch\n    gl_project.save()\n    logging.info(\"all done with GitLab host %s\", forge_url)\n\n\ndef guess_remote_urls(remote):\n    \"\"\"convenience wrapper around parse_remote_urls\"\"\"\n    return parse_remote_urls(\n        check_output((\"git\", \"remote\", \"get-url\", remote)).strip().decode(\"utf-8\")\n    )\n\n\ndef parse_remote_urls(remote_url):\n    \"\"\"this mess looks at the git remote URL and tries to guess a bunch of things\n\n    In particular, it tries to guess an HTTP URL from a SSH-looking\n    URL. Then It will try to guess the project (whatever comes after\n    the slash), and *then* the name of the site, which we call the\n    \"forge_url\", on which the site is hosted.\n\n    >>> parse_remote_urls(\"https://example.com/foo.git\")\n    ('example.com', 'https://example.com/foo.git', 'https://example.com/', 'foo')\n    >>> parse_remote_urls(\"git@example.com:foo.git\")\n    ('git@example.com', 'https://example.com/foo.git', 'https://example.com/', 'foo')\n    >>> parse_remote_urls(\"ssh://example.com/foo.git\")\n    ('example.com', 'https://example.com/foo.git', 'https://example.com/', 'foo')\n\n    Other URL formats are untested.\n    \"\"\"\n    remote_ssh = remote_url_http = remote_url\n    if \"@\" in remote_url:\n        remote_url_http = re.sub(r\".*@\", \"https://\", remote_url.replace(\":\", \"/\"))\n        logging.warning(\"rewritten URL %s to %s\", remote_url, remote_url_http)\n        remote_ssh = re.sub(\":.*\", \"\", remote_ssh)\n    elif remote_url.startswith(\"ssh://\"):\n        # strip leading ssh://\n        remote_ssh = re.sub(r\"^ssh://\", \"\", remote_url)\n        remote_url_http = \"https://\" + remote_ssh\n        # strip project path to keep just user@host.example.com\n        remote_ssh = re.sub(r\"/.*\", \"\", remote_ssh)\n    elif remote_url.startswith(\"https://\"):\n        # strip project path and url, keeping only host.example.com\n        remote_ssh = re.sub(r\"/.*\", \"\", re.sub(r\"^https://\", \"\", remote_url))\n    else:\n        assert not remote_url.startswith(\"http://\"), \"cleartext HTTP URL unsupported\"\n        logging.warning(\"unsupported scheme for remote URL: %s\", remote_url)\n\n    logging.info(\"guessed remote URL %s\", remote_url_http)\n    project = re.sub(r\"^https://[^/]*/(.*?)(\\.git)?$\", r\"\\1\", remote_url_http)\n    logging.info(\"guessed project path %s\", project)\n\n    forge_url = re.sub(r\"^(https://[^/]*/).*$\", r\"\\1\", remote_url_http)\n    logging.info(\"guessed forge URL %s\", forge_url)\n    return remote_ssh, remote_url_http, forge_url, project\n\n\nclass LoggingAction(argparse.Action):\n    \"\"\"change log level on the fly\n\n    The logging system should be initialized befure this, using\n    `basicConfig`.\"\"\"\n\n    def __init__(self, *args, **kwargs):\n        \"\"\"setup the action parameters\n\n        This enforces a selection of logging levels. It also checks if\n        const is provided, in which case we assume it's an argument\n        like `--verbose` or `--debug` without an argument.\n        \"\"\"\n        kwargs[\"choices\"] = logging._nameToLevel.keys()\n        if \"const\" in kwargs:\n            kwargs[\"nargs\"] = 0\n        super().__init__(*args, **kwargs)\n\n    def __call__(self, parser, ns, values, option):\n        \"\"\"if const was specified it means argument-less parameters\"\"\"\n        if self.const:\n            logging.getLogger(\"\").setLevel(self.const)\n        else:\n            logging.getLogger(\"\").setLevel(values)\n        # cargo-culted from _StoreConstAction\n        setattr(ns, self.dest, self.const)\n\n\nclass RenamerArgumentParser(argparse.ArgumentParser):\n    def __init__(self, *args, **kwargs):\n        \"add parameters to the argument parser\"\n        super().__init__(\n            description=\"rename a git branch locally and remotely\",\n            epilog=__doc__,\n            *args,\n            *kwargs,\n        )\n        self.add_argument(\n            \"-f\",\n            \"--from-branch\",\n            default=\"master\",\n            help=\"branch to rename from, default: %(default)s\",\n        )\n        self.add_argument(\n            \"-t\",\n            \"--to-branch\",\n            default=\"main\",\n            help=\"branch to rename to, default: %(default)s\",\n        )\n        self.add_argument(\n            \"-r\",\n            \"--remote\",\n            default=\"origin\",\n            help=\"remote to also operate on, default: %(default)s\",\n        )\n        self.add_argument(\n            \"-q\",\n            \"--quiet\",\n            action=LoggingAction,\n            const=\"WARNING\",\n            help=\"enable verbose messages\",\n        )\n        self.add_argument(\n            \"-d\",\n            \"--debug\",\n            action=LoggingAction,\n            const=\"DEBUG\",\n            help=\"enable debugging messages\",\n        )\n\n\nif __name__ == \"__main__\":\n    main()\n"},{"id":"422843","messageId":"60836fa129078_ff602089c@natae.notmuch","threadId":"55550","inReplyTo":"87mttofs5t.fsf@angela.anarc.at","subject":"RE: how to rename remote branches, the long way","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-24T01:08:49Z","receivedAt":"2021-04-24T01:08:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Antoine Beaupré wrote:\n> Before people start throwing things (like `git push origin oldref:newref\n> :oldref`) at me, consider that I've been beating my head against this\n> for a while, and everywhere I look basically suggests this:\n> \n>     git branch -m to_branch\n>     git push origin from_branch:to_branch :from_branch\n\nBetter:\n\n  git push origin from_branch:to_branch :from_branch &&\n  git branch -m from_branch to_branch\n\n> I wrote this primarily with the \"master to main\" migration, because a\n> bunch of projects (including mine) are suddenly, actually migrating\n> their main branch from master to main. Personnally, it's because I'm\n> tired of being yelled \"master\" from my shell prompt all the time, but\n> naturally, I guess opinions on the matter vary.\n\nJust tell git to stop bothering you:\n\n  git config --global init.defaultbranch master\n\n-- \nFelipe Contreras"},{"id":"422844","messageId":"87k0osfpt8.fsf@angela.anarc.at","threadId":"55550","inReplyTo":"60836fa129078_ff602089c@natae.notmuch","subject":"RE: how to rename remote branches, the long way","fromName":"Antoine Beaupré","fromEmail":"anarcat@debian.org","sentAt":"2021-04-24T01:12:51Z","receivedAt":"2021-04-24T01:12:54Z","isPatch":false,"sender":{"key":"anarcat@debian.org","avatar":"https://avatars.githubusercontent.com/u/796623?v=4"},"body":"On 2021-04-23 20:08:49, Felipe Contreras wrote:\n> Antoine Beaupré wrote:\n>> Before people start throwing things (like `git push origin oldref:newref\n>> :oldref`) at me, consider that I've been beating my head against this\n>> for a while, and everywhere I look basically suggests this:\n>> \n>>     git branch -m to_branch\n>>     git push origin from_branch:to_branch :from_branch\n>\n> Better:\n>\n>   git push origin from_branch:to_branch :from_branch &&\n>   git branch -m from_branch to_branch\n\nHow so?\n\n>> I wrote this primarily with the \"master to main\" migration, because a\n>> bunch of projects (including mine) are suddenly, actually migrating\n>> their main branch from master to main. Personnally, it's because I'm\n>> tired of being yelled \"master\" from my shell prompt all the time, but\n>> naturally, I guess opinions on the matter vary.\n>\n> Just tell git to stop bothering you:\n>\n>   git config --global init.defaultbranch master\n\nI think you misunderstood me; I am tired of seeing the name \"master\"\neverywhere. I actually did this, when it started working:\n\n    git config --global init.defaultbranch main\n\nAnd the reason I wrote this is to fix legacy.\n\nA.\n\n-- \nIn god we trust, others pay cash.\n                        - Richard Desjardins, Miami\n"},{"id":"422848","messageId":"60839422353fc_10cb9208c7@natae.notmuch","threadId":"55550","inReplyTo":"87k0osfpt8.fsf@angela.anarc.at","subject":"RE: how to rename remote branches, the long way","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-24T03:44:34Z","receivedAt":"2021-04-24T03:46:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Antoine Beaupré wrote:\n> On 2021-04-23 20:08:49, Felipe Contreras wrote:\n> > Antoine Beaupré wrote:\n> >> Before people start throwing things (like `git push origin oldref:newref\n> >> :oldref`) at me, consider that I've been beating my head against this\n> >> for a while, and everywhere I look basically suggests this:\n> >> \n> >>     git branch -m to_branch\n> >>     git push origin from_branch:to_branch :from_branch\n> >\n> > Better:\n> >\n> >   git push origin from_branch:to_branch :from_branch &&\n> >   git branch -m from_branch to_branch\n> \n> How so?\n\nIf the remote branch can't be renamed, then the local branch isn't\nrenamed either.\n\n> >> I wrote this primarily with the \"master to main\" migration, because a\n> >> bunch of projects (including mine) are suddenly, actually migrating\n> >> their main branch from master to main. Personnally, it's because I'm\n> >> tired of being yelled \"master\" from my shell prompt all the time, but\n> >> naturally, I guess opinions on the matter vary.\n> >\n> > Just tell git to stop bothering you:\n> >\n> >   git config --global init.defaultbranch master\n> \n> I think you misunderstood me; I am tired of seeing the name \"master\"\n> everywhere.\n\nI see.\n\nThat makes me think we might want a converter that translates\n(local)main -> (remote)master, and (remote)master -> (local)mail\neverywhere, so if your eyes have trouble seeing one, you can configure\ngit to simply see the other... Without bothering the rest of the word.\n\nI'll give that idea a try.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"422857","messageId":"87fszfafkh.fsf@angela.anarc.at","threadId":"55550","inReplyTo":"60839422353fc_10cb9208c7@natae.notmuch","subject":"RE: how to rename remote branches, the long way","fromName":"Antoine Beaupré","fromEmail":"anarcat@debian.org","sentAt":"2021-04-24T15:05:18Z","receivedAt":"2021-04-24T15:05:22Z","isPatch":false,"sender":{"key":"anarcat@debian.org","avatar":"https://avatars.githubusercontent.com/u/796623?v=4"},"body":"On 2021-04-23 22:44:34, Felipe Contreras wrote:\n\n[...]\n\nWell, that attempt at working with git upstream went about as bad as I\nexpected. I was afraid I'd get ignored or worse, get dragged into the\nnaming debate.\n\nSeems I got both, amazingly enough. I guess that I'll take that as a\n\"no, not welcome here\" and move on...\n\nA.\n"},{"id":"422858","messageId":"YIRXem9ApAsqgl6D@camp.crustytoothpaste.net","threadId":"55550","inReplyTo":"87mttofs5t.fsf@angela.anarc.at","subject":"Re: how to rename remote branches, the long way","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-24T17:38:02Z","receivedAt":"2021-04-24T17:38:52Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-24 at 00:22:06, Antoine Beaupré wrote:\n> For local branches, that doesn't matter much: no \"links\" should point\n> there. But git repos are, nowadays, living web sites on web servers like\n> GitHub, GitLab, cgit, or whatever. You have no way of telling those\n> sites \"I am renaming a branch\", so they don't have an opportunity of\n> fixing broken links (and, incidentally, bypassing branch protection,\n> although I actually use the GitLab API to workaround that problem).\n> \n> So I wonder: could git remote branch renames as an operation on remotes?\n> How would that look? Is that something that the git project should work\n> on? Or is this something strictly reserved to the API space of git\n> forges? In that case, how do I tell my gitolite server that it's okay\n> to rename a branch since it doesn't have an API? :)\n\nI think the ability to rename a branch, and to update the HEAD reference\n(and other symrefs) would be a nice protocol extension to add.  I've\nconsidered doing this in the past, but have never gotten around to it.\nIt's definitely a feature I'd like to see.\n\n> Or, maybe, should this script be sent as a [PATCH] instead and just be\n> merged into git itself? Maybe in contrib/? I do see some Python in\n> there, so I don't feel too much like an heretic... Obviously, it could\n> be rewritten in C, but it would feel such a pain in the back to me... I\n> already rewrote it from this shell script, which is still available\n> here:\n\nIn general, Git tries to remain neutral on forges and therefore we're\nprobably not super likely to adopt tooling that's specific to a set of\nforges.  I do, of course, think this script has utility and serves a\nparticular need for users, even though it's not likely that Git will\nhost it itself.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"422859","messageId":"8735vfa7bu.fsf@angela.anarc.at","threadId":"55550","inReplyTo":"YIRXem9ApAsqgl6D@camp.crustytoothpaste.net","subject":"Re: how to rename remote branches, the long way","fromName":"Antoine Beaupré","fromEmail":"anarcat@debian.org","sentAt":"2021-04-24T18:03:17Z","receivedAt":"2021-04-24T18:03:21Z","isPatch":false,"sender":{"key":"anarcat@debian.org","avatar":"https://avatars.githubusercontent.com/u/796623?v=4"},"body":"On 2021-04-24 17:38:02, brian m. carlson wrote:\n> On 2021-04-24 at 00:22:06, Antoine Beaupré wrote:\n\n[...]\n\n>> Or, maybe, should this script be sent as a [PATCH] instead and just be\n>> merged into git itself? Maybe in contrib/? I do see some Python in\n>> there, so I don't feel too much like an heretic... Obviously, it could\n>> be rewritten in C, but it would feel such a pain in the back to me... I\n>> already rewrote it from this shell script, which is still available\n>> here:\n>\n> In general, Git tries to remain neutral on forges and therefore we're\n> probably not super likely to adopt tooling that's specific to a set of\n> forges.  I do, of course, think this script has utility and serves a\n> particular need for users, even though it's not likely that Git will\n> host it itself.\n\nThanks. I have patched the script to avoid requiring the gitlab library\nto run, with that in mind. Of course, there's some forge-specific code\nin there, but if it's not available, it should work transparently, with\na \"plain\" SSH remote...\n\nBut I understand your perspective, thanks for the feedback.\n\na.\n-- \nLa démocratie réelle se définit d'abord et avant tout par la\nparticipation massive des citoyens à la gestion des affaires de la cité.\nElle est directe et participative. Elle trouve son expression la plus\nauthentique dans l'assemblée populaire et le dialogue permanent sur\nl'organisation de la vie en commun.  - De la servitude moderne\n"},{"id":"422860","messageId":"YIRiSJDem/JaBHuN@camp.crustytoothpaste.net","threadId":"55550","inReplyTo":"60839422353fc_10cb9208c7@natae.notmuch","subject":"Re: how to rename remote branches, the long way","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-24T18:24:08Z","receivedAt":"2021-04-24T18:24:46Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-24 at 03:44:34, Felipe Contreras wrote:\n> I see.\n> \n> That makes me think we might want a converter that translates\n> (local)main -> (remote)master, and (remote)master -> (local)mail\n> everywhere, so if your eyes have trouble seeing one, you can configure\n> git to simply see the other... Without bothering the rest of the word.\n> \n> I'll give that idea a try.\n\nI don't believe this is a helpful response, and judging from the\nfollow-up, neither did the OP.  They're not trying to do anything\ndangerous, improvident, or harmful to others and they are trying to\nsolve a problem that many people have and that is due to an inherent\nlimitation in Git (its inability to rename remote branches easily[0]), so\nthere's no reason to respond in this way.\n\nThere is a difference between being firm and steadfast, such as when\nresponding to someone who repeatedly advocates an inadvisable technical\napproach, and being rude and sarcastic, especially to someone who is\ngenuinely trying to improve things, and I think this crosses the line.\nI'd appreciate it if we could aim to avoid the latter type of response\nand not scare off new participants to the community right away.\n\nI realize I also sometimes fall short of where I should be in terms of\nkindness on the list and elsewhere, but I hope we'll all endeavor to do\nbetter here.\n\n[0] Regardless of how you feel about this _particular_ rename, one would\nwant the ability to do this to preserve reflogs for _all_ remote\nrenames, and so this would be a valuable and desirable feature to have\nin Git anyway.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"423220","messageId":"6089fc7675b95_a9ef2089d@natae.notmuch","threadId":"55550","inReplyTo":"87fszfafkh.fsf@angela.anarc.at","subject":"RE: how to rename remote branches, the long way","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-29T00:23:18Z","receivedAt":"2021-04-29T00:23:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Antoine Beaupré wrote:\n> On 2021-04-23 22:44:34, Felipe Contreras wrote:\n> \n> [...]\n> \n> Well, that attempt at working with git upstream went about as bad as I\n> expected. I was afraid I'd get ignored or worse, get dragged into the\n> naming debate.\n> \n> Seems I got both, amazingly enough. I guess that I'll take that as a\n> \"no, not welcome here\" and move on...\n\nDo not take my response as representative of the views community.\n\nI do believe there's value in your patch, I'm just not personally\ninterested in exploring it. I don't see much value in renaming branches,\nespecially on a distributed SCM where the names are replicated in\ndozens, potentially thousands of repositories. But that's just me.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"423222","messageId":"6089fdc1bfc0f_a9ef2081e@natae.notmuch","threadId":"55550","inReplyTo":"YIRiSJDem/JaBHuN@camp.crustytoothpaste.net","subject":"Re: how to rename remote branches, the long way","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-29T00:28:49Z","receivedAt":"2021-04-29T00:28:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-04-24 at 03:44:34, Felipe Contreras wrote:\n> > I see.\n> > \n> > That makes me think we might want a converter that translates\n> > (local)main -> (remote)master, and (remote)master -> (local)mail\n> > everywhere, so if your eyes have trouble seeing one, you can configure\n> > git to simply see the other... Without bothering the rest of the word.\n> > \n> > I'll give that idea a try.\n> \n> I don't believe this is a helpful response, and judging from the\n> follow-up, neither did the OP.\n\nThat's fine, you don't need to find it useful.\n\n> They're not trying to do anything dangerous, improvident, or harmful\n> to others and they are trying to solve a problem that many people have\n> and that is due to an inherent limitation in Git (its inability to\n> rename remote branches easily[0]), so there's no reason to respond in\n> this way.\n\nWhat is \"in this way\"? Proposing another solution more people (including\nme) might find simpler, and more viable?\n\n> There is a difference between being firm and steadfast, such as when\n> responding to someone who repeatedly advocates an inadvisable technical\n> approach, and being rude and sarcastic, especially to someone who is\n> genuinely trying to improve things, and I think this crosses the line.\n\nI wasn't rude. You are free to disagree.\n\n> [0] Regardless of how you feel about this _particular_ rename, one would\n> want the ability to do this to preserve reflogs for _all_ remote\n> renames, and so this would be a valuable and desirable feature to have\n> in Git anyway.\n\nI never claimed otherwise.\n\nIt's perfectly fine for two people to work on two approaches to solve\nthe same problem.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}