list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Kaartic Sivaraam <>
Cc: Matt McCutchen <>,
Subject: Re: Renaming the "master" branch without breaking existing clones
Date: Mon, 03 Aug 2020 11:47:03 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Kaartic Sivaraam's message of "Mon, 3 Aug 2020 23:50:29 +0530")

Kaartic Sivaraam <> writes:

> On 03-08-2020 21:44, Junio C Hamano wrote:
>> If we wanted to do this properly, I'd imagine we'd need to add a
>> mechanism for repositories to convey "this branch that used to exist
>> got renamed to this other name", not specifically for any "special"
>> branch name (like 'master').  If we plan to never allow reusing the
>> old and banned name, it probably is enough to turn the old name into
>> a symbolic ref that points at the new name, e.g. in my repository
>>     $ git update-ref refs/heads/seen refs/heads/pu
>>     $ git update-ref -d refs/heads/pu
>>     $ git symbolic-ref refs/heads/pu refs/heads/seen
>> which would create a symbolic reference 'pu' that points at 'seen'
>> to say "pu used to exist but it is now seen".
>> But that would not work well, as we must allow reusing the old name,
>> as the primary point of renaming 'pu' to 'seen' in this project was
>> so that we can accept topics from contributors whose anglicized name
>> has 'p' and 'u' in capital letters as pu/$topicname branches.  Having
>> a symbolic ref 'pu' would defeat that plan.
> Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would
> hopefully not defeat the plan while being a little helpful ;)

How would that be helpful?  After all, I do want to allow us accept
a topic about 'seen' from author 'pu', and that pu/seen branch
should be different from the "not yet ready for 'next' but at least
the maintainer acknowledges that he has seen them" integration
branch whose name is 'seen'.

  reply	other threads:[~2020-08-03 18:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 12:15 Matt McCutchen
2020-08-03 16:00 ` Taylor Blau
2020-08-03 16:19   ` Junio C Hamano
2020-08-03 16:39     ` Taylor Blau
2020-08-03 19:40   ` Jeff King
2020-08-03 20:40     ` Junio C Hamano
2020-08-03 20:45     ` Jeff King
2020-08-03 21:02       ` Junio C Hamano
2020-08-03 21:11         ` Jeff King
2020-08-03 21:38           ` Junio C Hamano
2020-08-04  0:37     ` Matt McCutchen
2020-08-04  0:43   ` Matt McCutchen
2020-08-03 16:14 ` Junio C Hamano
2020-08-03 17:41   ` Matt McCutchen
2020-08-03 18:20   ` Kaartic Sivaraam
2020-08-03 18:47     ` Junio C Hamano [this message]
2020-08-04  8:50       ` Kaartic Sivaraam

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:

  List information:

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

  git send-email \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).