Re: [PATCH] grep: --full-tree

[Uri Okrent <uokrent@gmail.com>]

I've been following this thread for a long time and now I feel the
need to chime in...

On Fri, Nov 27, 2009 at 2:53 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> And it makes things inconsistent.  That is why I do not use it.

The number one problem my users have with git is inconsistent
behavior, both internally to git, and externally with respect to the
rest of the OS. But really, the issue is one of managing expectations,
which is where we here tend to fall down.

When you name the command grep, whether you like it of not,
you've bought into a certain set of expectations from the user
who has been using unix's grep since she was a baby. Saying,
"well, in git it works this way", (or saying "well in git those path
looking things you've been providing to commands are not really
paths, so don't expect them to act as such"), would make my
users want to vomit all over me, and then, not use git (a shame
since it's the best scm system around IMHO).

If we intend the behavior of the command to be materially different
from the good old unix standby, then we shouldn't use the same
name, and create the expectation that they are getting essentially
the same thing (git search, git pickaxe, or something carries no
semantic baggage---and no, I'm not suggesting we change the
name).

> I, for one, do not like Git's reputation...

There's the rub. How do we achieve consistency without breaking the
world? The short answer is, you really can't. As programmers we tend
to be a very timid bunch, but sometimes (and David A. can attest to
this, at least at dayjob) it's better to just make a change for the better,
and just deal with the breakages. It is possible to change behavior (and
even break some scripts! I firmly believe it is worthwhile sacrificing
some scripts on the altar of consistency).

The key once again, is managing expectations. We can't go around
changing everything willy-nilly, and we can't be continually changing
things. Here is where we could take a lesson from the python
community.

When they decided they needed to change things, they bundled a
bunch of backwards incompatible changes together and went for it.
Yes, Python 3 will break your scripts, but the most important thing is,
everybody knows it.

A similar thing was done here with the huge warning that push spits
out, but in the general case I would argue, that the wisest course is to
save backwards incompatible changes for a git 2 or something, where
we know we're breaking the world, and then scratch all our (well thought
out) backwards incompatible itches at once.

Whew. A bit of a rant, but there you go...
-- 
   Uri

Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/