Show 38 quoted lines
> On Wed, Feb 3, 2010 at 2:23 PM, Ron Garret <ron1@flownet.com> wrote:
> > In article
> > Ah. That explains everything. Thanks. (I thought git mv was
> > equivalent to git rm followed by git add. But it's not.)
>
> I suppose in this case it's not. The only difference is when your
> work tree differs from your index, though, and it's to be expected
> that 'git rm', in removing things from the index, would lose your
> ability to track those differences.
>
> > So... how *does* git decide when two blobs are different blobs and when
> > they are the same blob with mods? I asked this question before and was
> > pointed to the diffcore docs, but that didn't really clear things up.
> > That just describes all the different ways git can do diffs, not the
> > actual heuristics that git uses to track content.
>
> If you really want to know the details, looking at the code really is
> probably the best solution; it's not even that long.
>
> The short version is that git chooses a set of candidate blobs, then
> diffs them and figures out a percentage similarity between each pair.
> (A simple way to think of the similarity index is "how long is the
> diff compared to the file itself?" If the diff is of length zero, the
> similarity is 100%, and so on.) If the similarity is greater than a
> certain threshold, then it's considered to be the same file.
>
> Choosing the set of candidates is actually the more interesting
> problem, since detecting moves using the above algorithm is O(n^2)
> with the number of candidates. That's why 'git diff' and 'git log'
> don't do it at all by default.
>
> If you provide -M, the set of candidates is the set of files that were
> removed/modified and the set of files that were added. (Added files
> are compared against removed/modified files, iirc.) Normally that's a
> very short list. With -C, you need to compare all
> added/removed/modified files with all others, which is slightly more
> work. With --find-copies-harder, it becomes potentially a *lot* of
> work.