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@xxxxxxxxx> > --- > > * 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 -- 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