On Sun, Mar 1, 2009 at 12:09 PM, Paul Gortmaker
<paul.gortmaker@xxxxxxxxxxxxx> wrote:
>
> On Sun, Mar 1, 2009 at 11:17 AM, Jay Soffian <jaysoffian@xxxxxxxxx> wrote:
>> * Allowing the user to "git config sendemail.config never"
>
> I think it should be sendemail.confirm in the above.
Yep, thanks. Junio, please amend my commit message if v2 is acceptable as is.
> Thanks for
> taking this seriously -- I think lots of new git users (who probably
> will never make it to this list) will benefit from it without ever
> even knowing.
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.
--
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
