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

On Sun, Mar 1, 2009 at 12:09 PM, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:

Yep, thanks. Junio, please amend my commit message if v2 is acceptable as is.

Well it's all for naught unless Junio can be convinced that it's an acceptable trade-off. On this point I want to elaborate a little more, so pardon me while I step up on the soap box.

Once upon a time, all git commands were git-something and they were installed in PATH. A smattering of users complained about this. Eventually git learned "git something" in addition to "git-something". Then some folks decided why not just get rid of "git-something" entirely. And so it was done. And many other users who were happy with the way it was complained.

And rightly so. The change was made w/no escape hatch for those users. And to plumbing no less. The users who wanted "git-something" out of PATH (which wasn't really hurting anything) got what they wanted, but nothing was done to accommodate the existing users. Eventually a compromise was reached. The git-something commands moved out of PATH, but were still installed, and existing users could relatively easily get to them by adding "git --exec-path" to their PATH.

(Please correct me if my summary is wrong, but that's how I recall it.)

If the compromise is how it was done in the first place, perhaps Junio would not be as hyper-sensitive to any change which affects existing users expectations.

But this patch is not like the git-something situation. This patch benefits new (all?) users, while bending over backwards to accommodate existing users. And it is a porcelain change.

I sympathize with Junio's aversion to accepting patches which affect existing users expectations. But I also think there are times when the greater good is served by such patches, and it would be nice to have some guidelines for how and when such patches can be made. For example:

- No non-backwards compatible changes to plumbing.
- Non-backwards compatible changes to porcelain IFF:
  - The change provides a notable (non-trivial) benefit to new users.
    Some litmus tests for such a change might be:
    - "in hindsight, this is how it clearly should've been done."
    - "this is really confusing for new users; existing users users have
      forgotten how confusing it was when they first encountered it."
    - "the default behavior is potentially dangerous/embarrassing."
  - Existing users can easily get the prior behavior. i.e. via a config
    setting
  - The change, where possible, maintains previous expectations if it
    appears the command is being used by an experienced user.

(In fairness, there appears to be a framework for non-backwards compatible changes; you introduce a warning about the change in the next minor release that the behavior of X will change and inform the user how they can keep the existing behavior of X; wait one patch release, then make the actual change. But my reading of Junio's message is that he doesn't think _this_ patch is even worthy of that step until I can demonstrate that there is not a silent-majority who really likes the existing behavior of send-email. But as I said, this is not my itch, and while I'm happy to offer up this patch, that's as far as I go.)

Stepping off soapbox.

j.