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

From: Jeff King <peff@peff.net>
Date: May 8, 2010, 05:30 UTC
Message-ID: <20100508053025.GG14998@coredump.intra.peff.net>
In-Reply-To: <19428.62170.654092.308682@winooski.ccs.neu.edu>

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

Show 9 quoted lines

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

Show 14 quoted lines

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

Show 9 quoted lines

> 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