Re: detecting rename->commit->modify->commit

From: Teemu Likonen <tlikonen@iki.fi>
Date: May 1, 2008, 20:39 UTC
Message-ID: <20080501203940.GA3524@mithlond.arda.local>
In-Reply-To: <20080501152035.GB11145@sigill.intra.peff.net>

Jeff King wrote (2008-05-01 11:20 -0400):

> Hmm, looking at the code, though, 50% is supposed to be the default
> minimum. So there might actually be a bug.

I did some testing... A file, containing 10 lines (about 200 bytes), renamed and then modified (similarity index being a bit over 50%). Git detected the rename just fine with "git diff -M" over the rename and change. When I edited the file even more (similarity only 40%) "git diff -M" didn't detect the rename but "git diff -M4" did. To me it looks like this works nicely, better than I expected, actually.

Smaller files than that do not seem to work with "git diff -M" over the rename and changes. They can be followed with "git log --follow -p" which works even with the two-line "hello\nworld". And of course there is always

  git diff commit1:path1/file1 commit2:path2/file2

I'd conclude that for logs and diffs renames are detected very nicely and there's no problem at all to get wanted information from the repo. I wonder how this rename detection/tracking has become such a big thing, a debate even. But maybe merges are different.