On Sat, May 08, 2010 at 01:12:58AM -0400, Eli Barzilay wrote: > > > BTW, I've had at least 4 people now who got confused by this. Is > > > there any use for -M/-C without --follow? In any case, it will be > > > very helpful if the -M/-C descriptions said "see also --follow". > > > > Yes, it detects renames when doing diffs. > > OK, so just to clear this up: -C and -M (and --find-copies-harder) are > for `diff', and --follow is for `log' with a single file (and each > will pass it on to the other)? Yes (well, diff can never pass --follow to log, since diff never invokes log, but yes, the per-commit diff shown by log uses the -C and -M given to log). > > Documentation patch is below. > > Thanks! (It would also be nice to mention it in -C, but not critical > since it's right after -M.) Yeah, I considered that, but didn't because of the proximity. But maybe it would make sense to do so, or to point -C at -M (e.g., say "like -M, but detect copies as well as renames"). > Well, the "algorithm" I used was probably one that is very popular: > > * use `git log some-file' with something that got renamed recently > * be horrified that all history is gone > * remember something vague about git detecting renames => go look at > the man page > * Find -M, add it, try it, still doesn't work > * Go back to scanning the man page, repeat > * At the end I end up with: > -C -M --find-copies-harder --follow > > So if there was some single > > --do-whatever-you-can-as-much-as-you-can-to-find-all-renames But I think all you really wanted was "--follow". I'd have to check the code, but I'm not even sure whether "-C" will impact --follow at all. > Even with the chain of more flags with descriptions that sound like > they're trying to scare me away by promising that my machine will work > for a REALLY LONG TIME, I'd still want to turn it on -- if it got > something slower I sure didn't notice it so far, and that's on a real > repository which is not that small (but with git's reputation I won't > be surprised if "slower" means that I had to way a whole extra 20ms > for an answer...). If something would really take too long, as in me > sitting any waiting for an answer, *then* I can try to remove that and > see if I ran into some of the horrible edge cases... No, copy detection can be _really_ slow. There is a reason it isn't on by default. Try "git log -1000 -p" versus "git log -1000 -p -C -M --find-copies-harder" in some repository. In a simple git.git test, it is almost 5x slower (about 1 second versus 5 seconds on my machine). For large repositories, it can be much worse, because now each diff is O(size of repository) instead of O(size of changes). Still, I see your point that you might want it on all the time, if you have a sufficiently small repo. There is "diff.renames" to turn on rename detection all the time. But I think a log.follow option doesn't make sense at this point. For example: $ git config log.follow true $ git log foo.c ;# ok, follow foo.c $ git log foo.c bar.c ;# uh oh, now what? Does the last one just barf, and make you say "git log --no-follow foo.c bar.c"? Does it quietly turn off --follow, making the user guess why "git log foo.c" finds some history that "git log foo.c bar.c" doesn't? -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