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

[Junio C Hamano <gitster@pobox.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?

> 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?