Re: [WARNING] Proposed future changes that are backward incompatible

From: George Spelvin <linux@horizon.com>
Date: Feb 27, 2009, 20:31 UTC
Message-ID: <20090227203108.10186.qmail@science.horizon.com>
In-Reply-To: <7v3adzk5wb.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> "George Spelvin" <linux@horizon.com> writes:
>
> > There's one more change that was suggested that I'd like to propose:
> > - Make "git grep" search the whole repository by default; include an
> >   explicit "." path limiter to search only the current directory.
> >
> > In addition to being more consistent with other commands like "git log",
> > this saves a lot of typing working in drivers/net/usb/ if the identifier
> > you're looking for is in include/.  Typing the additional space-dot
> > is pretty trivial if you want the current directory only.
>
> I do not remember it was ever suggested, let alone coming to anything near
> consensus.

The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as http://marc.info/?l=git&m=123216049508531 but I agree that there was no consensus. I just thought this thread was a good place to elicit discussion, since it would be an incompatible change.

Show 10 quoted lines

> The only way you could justify such a default change is to say:
>
>     Almost all the time, everybody wants to use this new behaviour; the
>     old behaviour is almost never useful in any situation other than a
>     narrow corner case; and if somebody wants to do such a useless thing
>     in a corner case, he can always add " ." at the end, so nothing is
>     lost.
>
> I do not think that is true for the change you are proposing here.  'He
> can always add " ." at the end' alone is not a good enough justification.

Please forgive me, I thought the above *might* be true, and wanted to provoke discussion to see how people felt. The "consistent with git-log and all that stuff" argument is quite persuasive to me, but it's a convenience feature, so it depends on how people feel.

> I however think your use case deserves to be supported, and I would not
> mind at all accepting a new "--full-tree" (or some shorter synonym) option
> if the patch is cleanly done (hint, hint).

Hint taken. Half of the patch is available at http://marc.info/?l=git&m=123207990016944

Is -t/--full-tree okay? I'd rather use -a/--all, but that's taken. -t isn't used by grep(1) either.

> I'd rather not add this to "future changes that are backward incompatible"
> list.  It may be a useful new feature, but that is not what the topic of
> this thread is about.

Sorry for veering off on an inappropriate tangent.