Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > The escape hatch was there from the beginning, is still there, and it > will remain there. I should also add that it was Junio's veto of > Linus'es proposal to stop installing git-foo commands for builtins > that enabled this escape hatch. I think veto is too strong a word to describe what really happened, but in retrospect, if we went ahead and removed built-ins from the filesystem as Linus and other people advocated, the escape hatch wouldn't have worked at all, so in that sense you are correct. But I do not think I deserve the credit for that---I do not see myself making an argument based on that "possible escape-hatch" value in that old thread. By the way, how are you researching these old discussions? Do you have a huge list of bookmarks? > By the way, I don't think the lesson you should take home is the need > for an escape hatch. Read the message by Junio on August 24th, > 2008. Being nice and not too loud during the deprecation period kept > users complacent about upcoming changes and upset them when the change > finally came. Being un-nice and too loud during the deprecation period > would have upset them early instead. You cannot avoid upsetting users > either way whenever you change the behavior. Yup. And the most scary part of all is that you cannot try both. We now know that for 1.6.0 transition people _claimed_ that they would have liked louder deprecation period than the way 1.6.0 transition was handled, but that is not (and cannot be) backed by real world experience. Nobody tried versions of git that warned loudly about the upcoming change every time he typed "git-commit" to see if the louder deprecation period was really preferrable. We are taking that route for 1.7.0 to warn very loudly about pushing into the currently checked-out branch in 1.6.2 and onwards. We may now find out that people hate a loud deprecation period. Then what? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
