renaming question

renaming question

[Aaron Gray]

I have a very large C source project that I am converting from C to C++.

Is it posssible to track changes with renamed files in GIT ?

I really want to enter the C source into GIT then enter the C++ conversion 
and have GIT track changes.

Is this possible and if so how do I do it ?

Many thanks in advance,

Aaron

Re: renaming question

[Florian Weimer]

* Aaron Gray:

> I have a very large C source project that I am converting from C to C++.
>
> Is it posssible to track changes with renamed files in GIT ?

You don't need to rename the files if you compile them using g++.  If
you still want to rename them, most history-related GIT commands
accept an -M switch which enables rename ("move") detection.

Re: renaming question

[Aaron Gray]

>* Aaron Gray:
>
>> I have a very large C source project that I am converting from C to C++.
>>
>> Is it posssible to track changes with renamed files in GIT ?
>
> You don't need to rename the files if you compile them using g++.  If
> you still want to rename them, most history-related GIT commands
> accept an -M switch which enables rename ("move") detection.

For sanity they have to be renamed.

I am a bit of a GIT newbie. With the -M switch what would be the proceedure 
with a single file conversion such as with test.c and test.cpp ?

Would the following do the trick ?

    git add test.c
    git commit

    rename test.c test.cpp *
    vi test.cpp

    git rm test.c
    git add test.cpp
    git commit -M

Many thanks in advance,

Aaron

Re: renaming question

[David Kastrup]

"Aaron Gray" <angray@beeb.net> writes:

>>* Aaron Gray:
>>
>>> I have a very large C source project that I am converting from C to C++.
>>>
>>> Is it posssible to track changes with renamed files in GIT ?
>>
>> You don't need to rename the files if you compile them using g++.  If
>> you still want to rename them, most history-related GIT commands
>> accept an -M switch which enables rename ("move") detection.
>
> For sanity they have to be renamed.
>
> I am a bit of a GIT newbie. With the -M switch what would be the
> proceedure with a single file conversion such as with test.c and
> test.cpp ?
>
> Would the following do the trick ?
>
>    git add test.c
>    git commit
>
>    rename test.c test.cpp *
>    vi test.cpp
>
>    git rm test.c
>    git add test.cpp
>    git commit -M
>
> Many thanks in advance,

There is no such thing as "git commit -M".  git does not keep track of
renames.  It generates the rename info on the fly when you ask it for
patches, log stats, blame annotations or similar.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: renaming question

[Aaron Gray]

> "Aaron Gray" <angray@beeb.net> writes:
>
>>>* Aaron Gray:
>>>
>>>> I have a very large C source project that I am converting from C to 
>>>> C++.
>>>>
>>>> Is it posssible to track changes with renamed files in GIT ?
>>>
>>> You don't need to rename the files if you compile them using g++.  If
>>> you still want to rename them, most history-related GIT commands
>>> accept an -M switch which enables rename ("move") detection.
>>
>> For sanity they have to be renamed.
>>
>> I am a bit of a GIT newbie. With the -M switch what would be the
>> proceedure with a single file conversion such as with test.c and
>> test.cpp ?
>>
>> Would the following do the trick ?
>>
>>    git add test.c
>>    git commit
>>
>>    rename test.c test.cpp *
>>    vi test.cpp
>>
>>    git rm test.c
>>    git add test.cpp
>>    git commit -M
>>
>> Many thanks in advance,
>
> There is no such thing as "git commit -M".  git does not keep track of
> renames.  It generates the rename info on the fly when you ask it for
> patches, log stats, blame annotations or similar.

Could you elaborate maybe with a rough example for generating patches.

Aaron

Re: renaming question

[David Kastrup]

"Aaron Gray" <angray@beeb.net> writes:

>> "Aaron Gray" <angray@beeb.net> writes:
>>>
>>> Would the following do the trick ?
>>>
>>>    git add test.c
>>>    git commit
>>>
>>>    rename test.c test.cpp *
>>>    vi test.cpp
>>>
>>>    git rm test.c
>>>    git add test.cpp
>>>    git commit -M
>>>
>>> Many thanks in advance,
>>
>> There is no such thing as "git commit -M".  git does not keep track
>> of renames.  It generates the rename info on the fly when you ask
>> it for patches, log stats, blame annotations or similar.
>
> Could you elaborate maybe with a rough example for generating
> patches.

Uh, is that a trick question?

git-format-patch -M

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: renaming question

[Florian Weimer]

* David Kastrup:

>> Could you elaborate maybe with a rough example for generating
>> patches.

> git-format-patch -M

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.)

Re: renaming question

[Steven Grimm]

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. 
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

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".

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.)

-Steve

Re: renaming question

[Aaron Gray]

> 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

Re: renaming question

[Shawn O. Pearce]

Steven Grimm <koreth@midwinter.com> wrote:
> 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.)

And if you have a GUI available, try `git gui blame $file`.  It runs
git-blame twice to show you not only where the content originally
came from, but also who put it where it is now.  Still needs more
polish, but its quite useful as it is.

-- 
Shawn.

Re: renaming question

[VMiklos]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

Hello,

Na Sun, Aug 19, 2007 at 07:32:01PM +0100, Aaron Gray <angray@beeb.net> pisal(a):
>    rename test.c test.cpp *
>    vi test.cpp

>    git rm test.c
>    git add test.cpp

or just git mv test.c test.cpp

- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: renaming question

[Aaron Gray]

Hello,

>Na Sun, Aug 19, 2007 at 07:32:01PM +0100, Aaron Gray <angray@beeb.net> 
>pisal(a):
>>    rename test.c test.cpp *
>>    vi test.cpp

>>    git rm test.c
>>    git add test.cpp

>or just git mv test.c test.cpp

Yes I gathered that.

followed by 'vi test.cpp' :)

GIT's looking great, cannot wait to really start using it.

Aaron