Re: Renaming the "master" branch without breaking existing clones

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2020, 21:38 UTC
Message-ID: <xmqqwo2ftnoz.fsf@gitster.c.googlers.com>
In-Reply-To: <20200803211112.GA2720049@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> But I do think a "branch renaming" helper like this might be useful for
> projects undergoing this rename. I don't think it makes sense to have as
> a first-class Git command, but I wouldn't be opposed to carrying
> something like it in contrib/ if somebody wanted to polish it up.

Absolutely.

I think we three are on the same page now ;-)

cf. <20200803163958.GD50799@syl.lan> cf. <xmqqlfivwvtw.fsf@gitster.c.googlers.com>

Now one issue I am not so sure about is if the only thing that needs adjusting is branch.*.remote + branch.*.merge.

The open-ended nature of our design means it is _possible_ to be reasonably sure to have covered everything we do in the core part of Git, but it is certain for us to miss third-party enhancements.

An inevitable "why not do all that when 'git branch -r -m old new' is given?" posed by those who are not aware of the design needs to be shot down, which is unfortunate.