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

Jeff King <peff@peff.net> writes:

Oh, I totally agree with you that what's convenient is different per <project, the role I play in the project> pair.

In my day-job project, I almost always work in a directory four levels down from the toplevel ("src/lib/u/<something>") and almost always what to run grep from near the top ("/src" in the strawman syntax to grep from that directory). I have similar preference when playing with projects I am not very familiar with---hack in a limited area somewhere deeper, but grep a lot more widely. So it is very tempting to say that I would want "full-tree" configured as default in these repositories.

But the conclusion I draw from that observation is that it should be equally easy for me to invoke both behaviours from the command line, and not "I want to freeze which default is used for the project by setting a configuration variable", because I know "the role I play" part changes from time to time (note that I didn't say "changes over time"---that can be addressed by "Then you should flip the config when the day comes").

At first sight, git.git is too shallow for "full-tree" vs "current directory" distinction to make any meaningful difference, especially because it is very top heavy and I almost always am at the top level directory. But even there, I can clearly see that I have need for easy access to both modes. I sometimes play a contributor who is interested in and is very familiar with a specific area (hence I know in which files to find strings without resorting to full-tree grep), and other times play a reviewer role who tries to follow what an area expert, who is much more familiar than me in some parts of the system, did in his patch. In the latter case, I would not know in which files to grep offhand, and would benefit from "tree-wide" option, in order to find out what is done by that obscure function the area expert used in his patch.

A repository-wide configuration would not help me at all, but a way to invoke either mode from the command line that is short-and-sweet would consistently give me the desired result without having to remember what the default-of-the-day (or default-in-the-repo) is.

But the above is mostly about "Peff wants config, Junio thinks it won't help him", and is not really a disagreement. As long as we don't use the existence of configurable defaults as an excuse for making/leaving it very cumbersome to invoke the non-default mode from command line, "it won't help some users" is not a reason to block it.

I suspect a per-repo configuration _might_ confuse new people (and people who help them), and I brought it up as a potential issue myself. That could be a more valid reason to object to configurable default, but I haven't formed an opinion how serious a problem it would be in real life; I should sleep on this one and wait for others' opinions.

Regardless of the above, there are unresolved issues in the --full-tree patch as posted.

We've been saying that even if the default were changed to grep in the full tree, limiting to the current directory is easy with a single "." at the end, but I do not think it is entirely true. I often want to grep in only "*.h" files but they are spread across the directories. If you do

    $ git grep -e frotz -- "*.h"

it finds in paths that match the pathspec in the current directory with today's default, but after we flip the default (either globally or with your configuration per-repo), it won't be possible to limit the search to header files in the current directory and under. It will find in header files spread over in the whole tree.

Also the --full-tree option I did at the beginning of this thread doesn't work with the above command line example, as it only kicks in when there is no pathspec.

Maybe these are not worth solving, and we should keep the current default and just tell ourselves to go up to the level we want to grep from. That would be simple, robust and the easiest to explain.