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