From: Michael J Gruber <git@drmicha•warpmail.net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] grep: --full-tree
Date: Wed, 25 Nov 2009 14:16:09 +0100 [thread overview]
Message-ID: <4B0D2E19.6020100@drmicha.warpmail.net> (raw)
In-Reply-To: <7vk4xggv27.fsf@alter.siamese.dyndns.org>
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 <gitster@pobox•com>
> ---
>
> * 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
next prev parent reply other threads:[~2009-11-25 13:17 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 8:56 [PATCH] grep: --full-tree Junio C Hamano
2009-11-25 13:16 ` Michael J Gruber [this message]
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 14:56 ` Sverre Rabbelier
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 20:19 ` Sverre Rabbelier
2009-11-25 20:23 ` Junio C Hamano
2009-11-25 20:46 ` Sverre Rabbelier
2009-11-25 23:31 ` Johannes Schindelin
2009-11-25 23:29 ` Sverre Rabbelier
2009-11-25 20:52 ` Jeff King
2009-11-25 20:39 ` Jeff King
2009-11-25 20:52 ` Junio C Hamano
2009-11-25 21:00 ` Jeff King
2009-11-25 21:33 ` Junio C Hamano
2009-11-25 21:49 ` Jeff King
2009-11-25 22:12 ` James Pickens
2009-11-25 22:20 ` Jeff King
2009-11-26 17:56 ` James Pickens
2009-11-27 6:20 ` Jeff King
2009-11-27 8:18 ` Junio C Hamano
2009-11-27 9:31 ` Johannes Schindelin
2009-11-27 9:59 ` Jeff King
2009-11-27 10:53 ` Johannes Schindelin
2009-11-27 16:27 ` Uri Okrent
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 18:47 ` Uri Okrent
2009-11-27 20:53 ` Jeff King
2009-11-29 19:50 ` Uri Okrent
2009-11-29 11:48 ` Felipe Contreras
2009-11-27 18:02 ` Jeff King
2009-11-27 20:07 ` Johannes Schindelin
2009-11-27 21:05 ` Jeff King
2009-11-29 10:28 ` Johannes Schindelin
2009-11-29 18:32 ` Jeff King
2009-11-29 19:49 ` Junio C Hamano
2009-11-29 12:13 ` Felipe Contreras
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 20:50 ` Jeff King
2009-11-29 10:21 ` Johannes Schindelin
2009-11-29 18:24 ` Jeff King
2009-11-27 10:37 ` Matthieu Moy
2009-11-27 10:56 ` Johannes Schindelin
2009-11-25 22:26 ` Wincent Colaiuta
2009-11-26 0:00 ` Junio C Hamano
2009-11-26 0:16 ` A Large Angry SCM
2009-11-26 0:20 ` Junio C Hamano
2009-11-26 0:30 ` A Large Angry SCM
2009-11-26 0:36 ` Junio C Hamano
2009-11-26 18:14 ` James Pickens
2009-11-25 22:19 ` Junio C Hamano
2009-11-25 22:26 ` Jeff King
2009-11-25 22:41 ` A Large Angry SCM
2009-11-25 22:53 ` Jeff King
2009-11-25 23:07 ` A Large Angry SCM
2009-11-25 23:22 ` Jeff King
2009-11-29 11:38 ` Felipe Contreras
2009-11-29 19:45 ` Uri Okrent
2009-11-26 0:02 ` Junio C Hamano
2009-11-27 6:22 ` Jeff King
2009-11-25 22:15 ` A Large Angry SCM
2009-11-25 22:21 ` Junio C Hamano
2009-11-25 22:31 ` A Large Angry SCM
2009-11-25 22:43 ` A Large Angry SCM
2009-11-25 23:34 ` Johannes Schindelin
2009-11-25 23:41 ` Junio C Hamano
2009-11-26 0:04 ` Johannes Schindelin
2009-11-26 0:13 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B0D2E19.6020100@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox