Re: [PATCH v2 0/3] Accommodate for pu having been renamed to seen

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2020, 17:38 UTC
Message-ID: <xmqq8sgc749a.fsf@gitster.c.googlers.com>
In-Reply-To: <20200624172425.GA152115@generichostname>

Denton Liu <liu.denton@gmail.com> writes:

Show 14 quoted lines

> On Wed, Jun 24, 2020 at 10:05:43AM -0700, Junio C Hamano wrote:
>> I do not know how many of you regularly have interacted with 'pu'
>> and now need to go through the same adjustment as I do.  Sorry for
>> using you as a guinea pig for an experiment for you know what to
>> gauge the cost.
>
> Heh, I was wondering if you had any ulterior motives ;)
>
> Since we're on the topic of the cost of renaming branches, I was reading
> a reply from you back in 2011 about how HEAD symrefs are the only valid
> ones[0]. I'm not sure if the situation has changed since then but
> perhaps we could officially expand the scope of symrefs to allow users
> to essentially alias branches? It might reduce the cost of performing
> branch renames by having a backwards compatible option.

It would be one way to transition, adding a symref in refs/heads/pu pointing at refs/heads/seen, but that unfortunately defeats the whole point of the rename, to make room for pu/<topic> hierarchy for contributors with names, in which P and U appear as the first and the last capital letters, respectively.

So, no, that won't be a solution, unfortunately.

I have an unused branch 'pu/nomore' in the primary repository I work in, so that my accidental "git checkout -B pu jch" will fail, which also takes advantage of this D/F conflict preventing a ref from being created.