Re: git confused by rename

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.10.10 08:54:50 -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > 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.

Oh, heh, my patch doesn't help in that case. It's still modify + rename
with it, of course, as -B still breaks the stuff apart. Me being
confused about -M reporting copies in some cases remains though, I had
really expected that only -C would detect copies. Of course, this
confusion is purely from a user's point of view, I have zero knowledge
about the involved code...

Björn