Quoting Jay Soffian <jaysoffian@xxxxxxxxx>: > (Please correct me if my summary is wrong, but that's how I recall it.) I think your summary has some things right. - Many people complained git-foo being on their paths in the past; - Version 1.6.0 removed git-foo from users' path; and - Many people didn't like the change after the fact. However, you are completely wrong about the escape hatch. If your judgement on how seriously you need to treat the backward compatibility is based on your understanding of the issue you summarized in your message, you need to reconsider what you are proposing, after learning from the true history. The transition plan was first announced officially as part of the release notes for version 1.5.4. It said three things: - Using dashed forms of git commands (e.g. "git-commit") from the command line has been informally deprecated since early 2006, but now it officially is, and will be removed in the future. Use dash-less forms (e.g. "git commit") instead. - Using dashed forms from your scripts, without first prepending the return value from "git --exec-path" to the scripts' PATH, has been informally deprecated since early 2006, but now it officially is. - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export PATH" early in your script is not deprecated with this change. Notice that: - "now" is December 1st, 2007. - "will be removed in the future" happened on August 17th, 2008 at version 1.6.0. - The notice EXPLICITLY promises to keep supporting the use of git-foo if you prepend output of 'git --exec-path'. In other words, there was an escape hatch that had been very carefully in preparation for nine months. The same escape hach, and the promise to keep supporting it, was repeated in the release notes for version 1.6.0. You can refresh your memory (or read it for the first time, if you weren't around back then) with a message from Junio on August 24th, 2008 after version 1.6.0 was released: http://thread.gmane.org/gmane.comp.version-control.git/93511 It summarized "the original plan" (read the message and find the phrase in the middle) and outlined how it should be implemented if the git community still wanted to go through with the plan. With the discussion that followed the message, the community decided not to do anything (also known as the "alternative A"). 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. http://thread.gmane.org/gmane.comp.version-control.git/51245/focus=51272 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. That's the lesson you should learn. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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
