Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Somewhat to my surprise when I found out, git-mv doesn't actually result in any extra metadata about the rename getting stored in the repository: "Git has a rename command git mv, but that is just for convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content." https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...

All content in git is exclusively addressed by its hash - there's no UUID for files or directories like bzr has. The only concept of history is in the parent-references in the commit objects. So tracking bits of code from commit to commit, between file moves etc, happens purely heuristically, without any support in the storage format.

Given that it works like that, I'm impressed every day that that works at all, and also how fast it is. You can make git-blame work extra hard at finding the renames/moves with extra switches (see http://jfire.io/blog/2012/03/07/code-archaeology-with-git/ - I almost automatically add "-wCCC" now), and it's still surprisingly snappy.

But as noted in the comments to the OP, merging when one branch renamed a tree and the other added files under the old tree name, probably still needs bzr's rename-support.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: