git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] send-email: add --confirm option

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 2, 2009, 09:01 UTC
Message-ID
<7v7i385meo.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20090302172401.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> 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?

Show 7 quoted lines
> 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?

Previous: Nanako ShiraishiNext: Nanako Shiraishi
Message 8 of 22 in “send-email: add --confirm option”
  1. send-email: add --confirm optionJay Soffian, Mar 1, 2009
  2. Junio C HamanoMar 1, 2009
  3. Jay SoffianMar 1, 2009
  4. send-email: add --confirm optionJay Soffian, Mar 1, 2009
  5. Paul GortmakerMar 1, 2009
  6. Jay SoffianMar 1, 2009
  7. Nanako ShiraishiMar 2, 2009
  8. Junio C HamanoMar 2, 2009
  9. Nanako ShiraishiMar 2, 2009
  10. Felipe ContrerasMar 2, 2009
  11. Jay SoffianMar 2, 2009
  12. Junio C HamanoMar 2, 2009
  13. Jay SoffianMar 2, 2009
  14. Junio C HamanoMar 3, 2009
  15. send-email: add --confirm option and configuration settingJay Soffian, Mar 3, 2009
  16. Junio C HamanoMar 3, 2009
  17. Nanako ShiraishiMar 3, 2009
  18. Bert WesargMar 3, 2009
  19. Jay SoffianMar 3, 2009
  20. Junio C HamanoMar 3, 2009
  21. Bert WesargMar 3, 2009
  22. Jay SoffianMar 3, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.