On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote: > * 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html