The master branch rename, and avoiding another v1.6.0 git-foo fiasco

[Felipe Contreras <felipe.contreras@gmail.com>]

Hello,

Some of you may remember the fiasco that was the v1.6.0 release, which
obsoleted all the git-foo commands, and caused a huge revolt among
users.

What you may not remember is the suggestion I gave Linus Torvalds to
avoid such issues in the future: [1]

  What other projects do is make very visible when something is
  deprecated, like a big, annoying, unbearable warning. Next time you
  deprecated a command it might be a good idea to add the warning each
  time the command is used, and obsolete it later on.

  Also, if it's a big change like this git- stuff, then do a major
  version bump.

  If you had marked 1.6 as 2.0, and added warnings when you deprecated
  the git-foo stuff then the users would have no excuse. It would have
  been obvious and this huge thread would have been avoided.

https://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/

[It's worthwhile to read (or reread) the thread to consider the
arguments back and forth.]

This is precisely what was done for Git 2.0, with the addition of
configurations such as "push.default" that enabled the new behavior,
and if unset, a huge warning was issued.

The deprecation period allowed users to become aware of the upcoming
changes, test them, complain about them, or simply disable the
warning, and continue as they were.

The Git project learned its lesson, and the transition to Git 2.0 was
much smoother than v1.6.

Now with the master branch rename we are treading on dangerous waters again.

Regardless of the reasoning behind (of which I didn't see much
discussion, and I can provide strong arguments against), the move will
affect *all* users. Such huge changes are meant for major
versions--like Git 3.0 (which we are due for).

It is not a question of changing one line of code, it's about updating
hundreds--probably thousands--of instances in various documentations
that assume the name of the branch to be "master". This is what I
argued back in 2008 when I pushed against the sudden move to "git
foo", although apparently too late to be considered. [2]

*If* we are going to rename the master branch, it should be with a
good reason, after discussing it appropriately, in a major release
(i.e. Git 3.0), after a period of deprecation, and a big warning to
invite users to provide feedback about the important upcoming change.
We can hedge these types of changes with a "core.mode=next"
configuration, as I argued back in 2013. [3]

If we don't, we are inviting what happened back in 2008 to happen again.

"Those who cannot remember the past are condemned to repeat it." --
George Santayana

Cheers.

[1] https://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/
[2] https://lore.kernel.org/git/94a0d4530808271709s4e96c5a7ie6152b2937f2234b@mail.gmail.com/
[3] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/

-- 
Felipe Contreras