11 Feb
2015
11 Feb
'15
3:56 p.m.
On 11/02/15 21:42, Daniel-Constantin Mierla wrote:
On 11/02/15 21:24, Olle E. Johansson wrote:
Looks like that doesn't work either -- digging in web more revealed:
-
https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_.22track.22_r…
Anyhow, git log --follow should be good enough. Also, git-blame does
--follow automatically.
I guess doing all in one commit is ok, with same results as split commit
for just file rename.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
On 11 Feb 2015, at 21:16, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
It seems to be git
behaviour when the change is consistent. Found on the
net that the rename itself should be a single commit in order to
preserve history in 'git log'. See:
-
https://coderwall.com/p/_csouq/renaming-and-changing-files-in-git-without-l…
Even with a rename as part of a bigger change, history can be seen when
using --follow for git-log, like:
git log --follow modules/uac_redirect/uac_redirect.c
But git web viewer don't do that usually. Therefore, it is better to do
just the rename as single commit. Eventually will work fine to see all
history.
You should use
git mv ...
in order to preserve the history of the file.
Removing existing one and adding it is losing that.
I did use "git mv"
$ git commit
[master e0a20eb] app_java Rename module interface file
8 files changed, 6 insertions(+), 6 deletions(-)
rename modules/app_java/{java_mod.c => app_java_mod.c} (100%)
rename modules/app_java/{java_mod.h => app_java_mod.h} (100%)
It is weird that the mail message shows something else...