Re: renaming question

["Aaron Gray" <angray@beeb.net>]

> Florian Weimer wrote:
>> Or, for more control about what gets put into patch, git-diff -M.
>> (As I wrote, most of the relevant commands accept an -M switch.)
>>
>
> The key point, and where the original writer is probably confused, is that 
> in git, renames are inferred from information in the repository.

Okay.

> You do not ever need to explicitly tell git about a rename. There is a 
> "git mv" command which is simply a convenience command; it is equivalent 
> to
>
> mv a b
> git add b
> git rm a

That makes things alot clearer, thanks.

> When you query history with the -M flag or do merges, git will notice that 
> the contents of the new file "b" are very similar to the old file "a" and 
> will treat it as a rename. (The contents don't have to match exactly; they 
> just have to be substantially similar.)
>
> This is not a perfect system -- there are known cases where it fails -- 
> but it has major advantages too. For example, you can unpack a third-party 
> tarfile into a git repository, commit it, then unpack the next version's 
> tarfile and commit that. Since you are using tar, nothing will have told 
> git about files that the upstream people renamed in between versions, but 
> git will detect them after the fact just as if you'd done "git mv".

Thats great, exactly what I want to do.

> Not only that, git can detect movement of content *within* files. Try 
> moving some code from one file to another and running "git blame -M -C -C" 
> on the target file; you will see git tell you that the content originally 
> came from the first file. Pretty sweet. (It's not the default since it 
> makes "git blame" slower.)

Okay. The documentation, or what I have read does not really explain this 
properly or concisely.

Thanks alot Steve.

Aaron