From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:45
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 <redacted>
---
* 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.
builtin-grep.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
@@ -732,6 +733,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)OPT_BIT('H',NULL,&opt.pathname,"show filenames",1),OPT_NEGBIT(0,"full-name",&opt.relative,"show filenames relative to top directory",1),+OPT_BIT(0,"full-tree",&full_tree,+"search from the top of the tree",1),OPT_BOOLEAN('l',"files-with-matches",&opt.name_only,"show only filenames instead of matching lines"),OPT_BOOLEAN(0,"name-only",&opt.name_only,
From: Michael J Gruber <hidden> Date: 2016-06-15 22:47:46
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 <redacted>
---
* 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
Heya,
On Tue, Nov 24, 2009 at 09:56, Junio C Hamano [off-list ref] wrote:
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.
I regularly rely on this behavior in my usage of git grep. For
example, the Melange project has this layout:
-- app
-- app/soc
-- app/django
-- app/... etc
-- scripts
-- tests
-- thirdparty
I almost always want only results from "app/soc", so when I run git
grep I do so from within "app/soc" to make sure I don't get false
positives from the many external sources we have.
Just chiming in for the "want to keep the current behavior" camp :).
PS: I don't mind having to set a config variable to keep the current
behavior though.
--
Cheers,
Sverre Rabbelier
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:46
Michael J Gruber [off-list ref] writes:
Junio C Hamano venit, vidit, dixit 24.11.2009 09:56:
quoted
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 <redacted>
---
* 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?
I do not think there is such a consensus for a blanket change like that.
If you are starting a discussion to build one for a particular change (not
necessarily the one you mentioned above) now, you are way too late for
1.7.0. The changes scheduled for 1.7.0 were glitches we have known for
quite some time, and more importantly had a concensus on _how_ they should
be handled long before 1.6.3 (May 6, 2009), and the most importantly, the
steps in the transition plan since then have already been executing.
- The plan for "git push" changes were already announced in 1.6.3, and
the first step of transition was implemented there.
- We already had consensus for changing the default "send-email"
threading behaviour before 1.6.2 and it was scheduled to happen in
1.6.3 but has been deferred until now.
- For a long time, it has been known that it is confusing and unexpected
to users that "git status" is a synonym for "git commit --dry-run".
The plan to make "git status" different from "git commit --dry-run" has
been done in mid August this year.
- For a long time, "git diff" considered -b/-w options are only for
controlling generation of patch text, and these options didn't affect
the exit status (when run with --exit-code) nor suppress the patch
header lines (i.e. "diff --git"). This could be argued as a bug (the
same way as "some commands are relative to cwd by default and others
are relative to the whole tree" can be), but it doesn't mean we can
blame user's scripts for relying on the bug and change the semantics
all of sudden. We had been cooking the change since May 2009 and
announcements were in all issues of "What's cooking" since Aug 2009 for
this change.
Also, please do not confuse 1.7.0 with a license for "I do not like this
and that, screw backward compatibility, and change things as if we were
building git from scratch without any existing users". We need a solid
transition plan to ease the pain for existing scripts and users.
As to ls-files, I haven't seen any good proposal of a smooth transition
plan (like what we laid out for a few semantic changes for "git push" for
1.7.0), if we were to eventually change it, and I personally do not think
there can be a smooth transition for that particular command. It is used
as a very low level building block for people's scripts, and I don't think
of a way to change its fundamental behaviour without causing people a lot
of extra work. I doubt you can easily build a concensus that the benefit
of "consistency" is worth it for such a change.
Side note. What we _could_ do is to make ls-files less (much less)
necessary at the UI level for you to _type_ from the command line.
Enumerate in what situations you used the command, think about the
reason for each of occasions why you used it (e.g. "after a conflicted
merge I wanted to find out which paths are still unresolved and
'ls-files -u' was the most convenient way"), and eliminate the reason
(e.g. "add a new (option to 'merge'|command) that reports the needed
information in much more readable way than 'ls-files -u' does).
The same applies to "$treeish:$path" syntax.
It may be convenient if there were to specify "I want to name the path in
HEAD~47 that corresponds to this file in the directory I am currently in."
But that does not necessarily mean we should change the semantics and
break existing users. One way to satisfy the wish without breaking
existing users would be to start accepting "$treeish:./$relative".
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:46
Sverre Rabbelier [off-list ref] writes:
I almost always want only results from "app/soc", so when I run git
grep I do so from within "app/soc" to make sure I don't get false
positives from the many external sources we have.
The standard answer given by others has been "you can always say '.' at
the end; having to remember/count number of ../ necessary is much much
more inconvenient".
PS: I don't mind having to set a config variable to keep the current
behavior though.
I've thought about it for five seconds before sending my patch, but
discarded it, because I do not see it as a good transition plan.
If it were something like "git-push", that is a purely Porcelain for
causing _effect_ to outside world, the customizable behaviour of the
command depending on which repository it is run is excusable and may even
be beneficial.
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.
So this change, if we were to do it, unfortunately has to be "we do it
once and for everybody" a flag day event, I think. That is what I am not
enthused about this patch.
Heya,
On Wed, Nov 25, 2009 at 20:32, Junio C Hamano [off-list ref] wrote:
The standard answer given by others has been "you can always say '.' at
the end; having to remember/count number of ../ necessary is much much
more inconvenient".
A commandline flag to keep the old behavior then perhaps? "git config
alias.gr 'grep --no-full-tree'" is not that hard to write either.
--
Cheers,
Sverre Rabbelier
Ironically, I argued for --full-tree behavior in the same thread, but
have since softened my view. What I have come to realize is that (for
me, anyway) it is very dependent on the organization of the project you
are working on.
For git.git, and most of my small-ish other projects, I want "git grep"
to search the full tree. But recently, I have been working on a
large-ish project imported from svn where the parts of interest to me
are rooted two directories deep (i.e., I am working in
"linux/subproject/", and I don't care at all what's happening in
"windows/otherproject"). I don't want grep hits from the other area to
clutter my output, and I especially don't want to waste time hitting the
disk for those pages, which are an order of magnitude larger than the
working set of files that are actually of interest to me.
On top of that, I think there are two ways within a logical subproject
to use subdirectories. In git.git, I tend to actually chdir into
Documentation/ or t/, because they have their own Makefiles. But for a
project that organizes its code into a bunch of module subdirectories
all driven by a top-level non-recursive Makefile, I tend to stay at the
root and actually do "vi module/foo.c; make".
So what that tells me is:
1. It is not necessarily the _developer_, but a combination of
developer and project that decides which behavior (of --full-tree
and the current behavior) is more useful. Which to me really points
to the utility of a config option.
2. It would be useful to have a "partial-tree" middle ground. In other
words, if I am in "linux/subproject/t", I would find it most
useful if "git grep" searched all of "linux/subproject".
Implementing that would become much more complex, though. Probably
the user would specify a list of rooted subprojects, and we would
prefix-match our path to find which one we were in, and then
do a full-tree grep on that subtree.
And yes, this is somewhat an argument in favor of splitting the
project into submodules. But I'd really rather not do that. They
introduce significant complexity, and the rest of git is so _good_
at ignoring uninteresting parts.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:47:46
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