Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > 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? 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". -- 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