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@xxxxxxxxxxxxxx/ [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@xxxxxxxxxxxxxx/ [2] https://lore.kernel.org/git/94a0d4530808271709s4e96c5a7ie6152b2937f2234b@xxxxxxxxxxxxxx/ [3] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@xxxxxxxxx/ -- Felipe Contreras
