How to keep log history when renaming and changing simultaneously

How to keep log history when renaming and changing simultaneously

[Urs Thuermann]

Sometimes I need to rename and change a file in one commit.  One
example would be a file foo.h that begins with

    #ifndef FOO_H
    #define FOO_H

which should be renamed bar.h and have the FOO_H changed to BAR_H.
In subversion I would

    svn mv foo.h bar.h; vi bar.h; svn ci

and then a

    svn log bar.h

also shows the history of that file when it was named foo.h.

This does not work in git.  After committing,

    git mv foo.h bar.h; vi bar.h; git commit -a

the command

    git log --follow bar.h

shows only the history of the file when it was named bar.h, but not
its life as foo.h.

The only workaround I found was to do the rename and the change in two
separate commits, so that git sees the same name and the same SHA hash
which allows it to follow the files' history.  This can be a problem
when the intermediate version with either only the change or only the
rename doesn't compile correctly.

Is there a better way to do this in git?

A similar problem is splitting a file into two files.  With subversion
I'd do

    printf "void foo() {}\nint main() { foo(); }\n" > prog.c
    svn add prog.c; svn ci -m "Add prog.c"

Then I would split

    svn cp prog.c foo.c; svn cp prog.c main.c; svn rm prog.c
    printf "2d\nwq\n" | ed foo.c; printf "1d\nwq\n" | ed main.c
    svn ci -m "Split prog.c"; svn up

and I get

    $ svn log -v
    ------------------------------------------------------------------------
    r2 | urs | 2017-04-17 10:03:06 +0200 (Mon, 17 Apr 2017) | 1 line
    Changed paths:
       A /foo.c (from /prog.c:1)
       A /main.c (from /prog.c:1)
       D /prog.c
    
    Split prog.c
    ------------------------------------------------------------------------
    r1 | urs | 2017-04-17 10:02:51 +0200 (Mon, 17 Apr 2017) | 1 line
    Changed paths:
       A /prog.c
    
    Add prog.c
    ------------------------------------------------------------------------

And I can also see this when I run svn log on one of both files.	
How could I do this in git?

urs

Re: How to keep log history when renaming and changing simultaneously

[Duy Nguyen]

On Mon, Apr 17, 2017 at 6:36 PM, Urs Thuermann <urs@isnogud.escape.de> wrote:
> Sometimes I need to rename and change a file in one commit.  One
> example would be a file foo.h that begins with
>
>     #ifndef FOO_H
>     #define FOO_H
>
> which should be renamed bar.h and have the FOO_H changed to BAR_H.
> In subversion I would
>
>     svn mv foo.h bar.h; vi bar.h; svn ci
>
> and then a
>
>     svn log bar.h
>
> also shows the history of that file when it was named foo.h.
>
> This does not work in git.
> ...
> Is there a better way to do this in git?

We could if we allowed rename annotation, similar to that "svn mv"
command. I worked on that a while back [1] then I stopped because of a
design conflict. But I'm almost convinced Jeff and Junio were right
(and I wrong) now so I will likely revive that series before 2019
hits.

[1] http://public-inbox.org/git/1453287968-26000-1-git-send-email-pclouds@gmail.com/
-- 
Duy

Re: How to keep log history when renaming and changing simultaneously

[Igor Djordjevic]

Hi Urs,

On 17/04/2017 13:36, Urs Thuermann wrote:
> Sometimes I need to rename and change a file in one commit.  One
> example would be a file foo.h that begins with
> 
>     #ifndef FOO_H
>     #define FOO_H
> 
> which should be renamed bar.h and have the FOO_H changed to BAR_H.
> In subversion I would
> 
>     svn mv foo.h bar.h; vi bar.h; svn ci
> 
> and then a
> 
>     svn log bar.h
> 
> also shows the history of that file when it was named foo.h.
> 
> This does not work in git.  After committing,
> 
>     git mv foo.h bar.h; vi bar.h; git commit -a
> 
> the command
> 
>     git log --follow bar.h
> 
> shows only the history of the file when it was named bar.h, but not
> its life as foo.h.
> 
> The only workaround I found was to do the rename and the change in two
> separate commits, so that git sees the same name and the same SHA hash
> which allows it to follow the files' history.  This can be a problem
> when the intermediate version with either only the change or only the
> rename doesn't compile correctly.
> 
> Is there a better way to do this in git?
> 
> A similar problem is splitting a file into two files.  With subversion
> I'd do
> 
>     printf "void foo() {}\nint main() { foo(); }\n" > prog.c
>     svn add prog.c; svn ci -m "Add prog.c"
> 
> Then I would split
> 
>     svn cp prog.c foo.c; svn cp prog.c main.c; svn rm prog.c
>     printf "2d\nwq\n" | ed foo.c; printf "1d\nwq\n" | ed main.c
>     svn ci -m "Split prog.c"; svn up
> 
> and I get
> 
>     $ svn log -v
>     ------------------------------------------------------------------------
>     r2 | urs | 2017-04-17 10:03:06 +0200 (Mon, 17 Apr 2017) | 1 line
>     Changed paths:
>        A /foo.c (from /prog.c:1)
>        A /main.c (from /prog.c:1)
>        D /prog.c
>     
>     Split prog.c
>     ------------------------------------------------------------------------
>     r1 | urs | 2017-04-17 10:02:51 +0200 (Mon, 17 Apr 2017) | 1 line
>     Changed paths:
>        A /prog.c
>     
>     Add prog.c
>     ------------------------------------------------------------------------
> 
> And I can also see this when I run svn log on one of both files.	
> How could I do this in git?

For both cases (renaming and splitting), would using `--find-copies` 
work for you? Perhaps with some low threshold value to start with, if 
the default one yields no results.

If interested, adding `--name-status` to the mix will show similarity 
percentage between old and new file(s).


For example, renaming (with edit):

    git log --follow --find-copies=10% --name-status -- bar.h

... yields something like this (sha1/author/date/message omitted 
for brevity):

    commit 2
    ...
    R034    foo.h   bar.h

    commit 1
    ...
    A       foo.h


Another example, splitting (with minor edits):

    git log --find-copies --name-status

... outputs something like this:

    commit 2
    ...
    C090    prog.c  foo.c
    R090    prog.c  main.c

    commit 1
    ...
    A       prog.c


Regards,
Buga

Re: How to keep log history when renaming and changing simultaneously

[Urs Thuermann]

Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:

> For both cases (renaming and splitting), would using `--find-copies` 
> work for you? Perhaps with some low threshold value to start with, if 
> the default one yields no results.
> 
> If interested, adding `--name-status` to the mix will show similarity 
> percentage between old and new file(s).

I didn't know --find-copies and --name-status and I've now looked them
up in the doc.  Looks interesting but instead of looking for
similarity it would be better IMHO if there was a command "git cp" and
that "git mv" and "git cp" were recorded in the history somehow.

I'm still using CVS (and SVN in some few cases) but considering
changing to git.  There are some things, however, that I can do more
easily in CVS (like editing CVS ,v files instead of git commit
--amend) and I need to learn more git before I want to change (and
migrate existing repos).

urs

Re: How to keep log history when renaming and changing simultaneously

[Jacob Keller]

On Mon, Apr 17, 2017 at 2:36 PM, Urs Thuermann <urs@isnogud.escape.de> wrote:
> Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:
>
>> For both cases (renaming and splitting), would using `--find-copies`
>> work for you? Perhaps with some low threshold value to start with, if
>> the default one yields no results.
>>
>> If interested, adding `--name-status` to the mix will show similarity
>> percentage between old and new file(s).
>
> I didn't know --find-copies and --name-status and I've now looked them
> up in the doc.  Looks interesting but instead of looking for
> similarity it would be better IMHO if there was a command "git cp" and
> that "git mv" and "git cp" were recorded in the history somehow.
>
> I'm still using CVS (and SVN in some few cases) but considering
> changing to git.  There are some things, however, that I can do more
> easily in CVS (like editing CVS ,v files instead of git commit
> --amend) and I need to learn more git before I want to change (and
> migrate existing repos).
>
> urs

Unfortunately I don't have a ready link to the message, but there is a
very good post from early on in Git's development where Linus explains
why Git does not store rename and copy information in the history.

Essentially, it's because that information can be regenerated from the
blobs later, and you can get better information with better algorithms
and you don't bake the original implementation into the history
forever.

Thanks,
Jake

Re: How to keep log history when renaming and changing simultaneously

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> Unfortunately I don't have a ready link to the message, but there is a
> very good post from early on in Git's development where Linus explains
> why Git does not store rename and copy information in the history.

One of the most important message in the list archive, gmane:217 aka

http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/