Re: git confused by rename

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 10, 2008, 15:54 UTC
Message-ID: <7v3aj4momt.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vabdcmp4n.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> "Michael P. Soulier" <msoulier@digitaltorque.ca> writes:
>
>> #       renamed:    templates/scrc/index.html -> templates/scrc/cres_taps.html
>> #       modified:   templates/scrc/index.html
>>
>> Looking at the last two lines here, there is obviously an issue.
>
> I am puzzled.

Not anymore.

> Looking at wt-status.c "renamed: A -> B" will be shown only when A and B
> are similar enough *and* there is no A remaining in the final result, and
> in such a case, "modified: A" should not be shown.

Except for one case.

Show 5 quoted lines

> Because git does not
> care how you created B (IOW, it does not matter if B was typed from
> scratch with copying and pasting, or created by copying and editing), the
> "renamed: A -> B" entry itself is not surprising nor look like a bug at
> all,...

The above observation of mine is correct, but I forgot that "git status" (and the comment in the commit template from "git commit") is generated internally with "diff-index -B -M". So if

 (0) had A but not B in the HEAD commit;
 (1) you created B that is very similar to the original A; and
 (2) you modified A beyond recognition;

then git will say "A was modified and B was created by renaming A".

> ... but its presense at the same time as "modified: A" does feel very
> fishy.

So this is not fishy anymore.

This however makes me wonder if "diff-index -B -M" should say B is copied (instead of being renamed) from A and A is modified in such a case. I do not think we would want to make such a change without thinking things, through.