Re: Re: git log -M -- filename is not working?

On Sat, May 08, 2010 at 01:12:58AM -0400, Eli Barzilay wrote:

quoted

quoted

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).

quoted

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