From: Aaron Gray <angray@beeb.net>
Date: Mon, 20 Aug 2007 01:30:54 GMT
Subject: Re: renaming question
Message-ID: <045a01c7e2c9$c1ccd940$0600a8c0@ze4427wm>
In-Reply-To: <46C8E421.8000408@midwinter.com>

> 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