On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote: > 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
