This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New file extension
- From: Steinar Bang <sb at dod dot no>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 21 Aug 2013 19:55:31 +0200
- Subject: Re: New file extension
- References: <CAAiZkiBbBe1YwUS+NP8hP-yCAZhEa-6VGXkhKLkRF3QrgWy_wA at mail dot gmail dot com> <20130729200826 dot GA31944 at virgil dot suse> <20130730090434 dot GF17022 at redhat dot com> <CAD_=9DRVc9iKUiq-KdVhMxKoQfnRtYCs3Nwqtqomc6d6RBF_mA at mail dot gmail dot com> <20130730122843 dot GD31944 at virgil dot suse>
>>>>> Martin Jambor <mjambor@suse.cz>:
> Well, IIRC mostly worries about history. SVN claims to be able to
> track history of renamed files but I use the git mirror now and I
> wonder what the history would show there. I would consider it very
> unfortunate if 'git blame' did not show the .c era history of the
> renamed files. But maybe it would just work.
It depends on how the rename if done. If a file is added that has the
exact same SHA1 hash as a file with a different path, then git assumes
that the new file is a copy of the other file, and blame and the log
history can be made to follow the history beyond the copy. Actually
"git blame" always follow the history across renames, and "git log"
needs the "--follow" option, or a config setting, to do so.
I have no idea what git-svn (or whatever) will do when it comes to an
svn rename, but it would make sense if it replicated it by a commit that
does a git rm of the file in the old location, and a git add of the file
in the new location.
If the svn rename also changes the renamed file, then things get
trickier... git-svn would have to split that commit into two.