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

From: Michael J Gruber <[email-masked]>
Date: Wed, 25 Nov 2009 14:16:09 +0100

Junio C Hamano venit, vidit, dixit 24.11.2009 09:56:
> While working inside a deep subdirectory, it sometimes is necessary to
> find a string you see in a file you are working on from the files in the
> entire project.  This is especially true when you are dipping your toe
> into an unfamiliar project.
> 
> By default, "git grep" limits its search space to the current directory
> and below (i.e. as if "-r ." is specified), and it is rather cumbersome to
> repeat ../ as many times as necessary.  This new option tells "git grep"
> not to limit the search space to the current directory.
> 
> Signed-off-by: Junio C Hamano <[email-masked]>
> ---
> 
>  * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
>    once argued in the opposite way, but I think it is Ok to aim for making
>    the default --full-tree in the longer run (cf. $gmane/127885).  This is
>    the first step in that direction.
> 
>    I am not sure if there can be a sane way to flip the default without
>    hurting existing scripts and users.  Backward compatibility always is
>    a pain.

On a related note, I had planned for a while now to go through the
commands and check for inconsistencies w.r.t. to subdir default. For
example, ls-files behaves like grep, whereas status is different. We
already had discussions about the commit:path notation from a subdir. (I
don't remember the outcome.) Of course, defaulting status differently
could be dangerous. Having --full-tree as default for all commands and
requiring an explicit "." sounds safer for all commands and not overly
inconvenient. (I remember once wondering where my committed files are,
looking at git ls-files output from a subdir.)

I think we should make this behavior as uniform across commands as
possible. Do we have a time frame for 1.7.0 within which one should
achieve such incompatible changes?

Michael