On Wed, Nov 25, 2009 at 11:32:44AM -0800, Junio C Hamano wrote:
> But if a command like "grep" that "does one small thing and do it well"
> changes its behaviour drastically depending on a config variable or an
> environment variable, it won't be a command that you can rely upon any
> more in your scripts and hooks. It's the same insanity as GREP_OPTIONS
> environment variable.
I know this is the attitude we have taken in the past, and I am worried
it is part of what hurts the usability of git. Just consider for a
moment: git grows some feature with a default behavior X. Time passes.
Some people like behavior Y instead. How can we help the people who like
Y?
1. Declare Y better than X, and default to it. This hurts people who
like X. It also hurts scripts built around X.
2. Add a config option to switch the behavior to Y. This hurts people
or scripts unexpectedly using somebody's configuration with Y.
3. Add a --Y command line option. Now the Y people have to remember to
use that option. Every single time they invoke the command.
4. Tell them to alias "git foo-y" to "git foo --Y". IMHO, this is
completely unscalable. They can't just call it "foo", so they have
to remember to invoke "foo-y" each time. And when they forget,
instead of getting an error, they get the X behavior. Furthermore,
as time goes on, they basically develop a vocabulary of git
commands that is totally unlike anybody else's, making their
scripts and git knowledge unportable to other people's setups (sort
of like in (2) above).
So as a Y user, what is the impression of git that I am left with? It
doesn't do what I want unless I remember an option every time, or create
an arcane pseudo-porcelain interface through my set of aliases. Patches
to fix the situation are blocked by compatibility issues. Y users remain
frustrated indefinitely.
I know that (1) and (2) have their problems. But I think by not giving a
little on those compatibility issues, we end up with an equally bad or
worse outcome. In other words, I think in this case that (2) may be the
lesser of many evils.
-Peff
--
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