How to keep log history when renaming and changing simultaneously

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

On Mon, Apr 17, 2017 at 6:36 PM, Urs Thuermann <urs@isnogud.escape.de> wrote:

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/

Hi Urs,

On 17/04/2017 13:36, Urs Thuermann wrote:

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

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

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

On Mon, Apr 17, 2017 at 2:36 PM, Urs Thuermann <urs@isnogud.escape.de> wrote:

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

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

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/