Re: Consensus on a new default branch name

From: Jeff King <peff@peff.net>
Date: Jun 16, 2020, 16:47 UTC
Message-ID: <20200616164715.GA678873@coredump.intra.peff.net>
In-Reply-To: <20200616161001.fa5wa2br5ois2csr@chatter.i7.local>

On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:

Show 15 quoted lines

> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:
> > 
> > My biggest concern here was trying to understand what could break.
> > Having read the patches from Johannes and thought about it a lot, I have
> > a pretty good handle on where Git itself cares about the name. And I
> > feel pretty confident that we can make the change in a way that won't
> > cause problems there (and in fact, I think some of the code will be
> > made more robust by relying on HEAD more appropriately).
> > 
> > There's a more open question of what _else_ will break in the ecosystem.
> 
> What if we work on making this configurable for now, but stick with the 
> legacy name until we introduce breaking sha1 changes? Almost everything 
> will need to retool for those anyway (and all documentation rewritten), 
> so it is reasonable to bundle these changes to happen at the same time.

I think that's a potential timetable we might use. It would be easier to consider if we actually had a timetable for the sha1 changes. :)

But I certainly agree that if the timing works out favorably, switching both defaults at once, with a big version number bump, would be nice.

I do think that the branch name change will have more far-reaching effects on documentation than a hash change. Mostly because hashes are random-looking garbage from a user's perspective anyway. So aside from people dealing with hash transitions, we'll mostly just need to update any hard-coded values in tutorials, examples, etc. Whereas I think the word "master" creeps into a lot of more substantive discussions as a synonym for "the main branch".

-Peff