Renaming is the killer app of distributed version control (2007) | Hacker News Reader

Renaming is the killer app of distributed version control (2007)

markshuttleworth.com

28 pointsyungchin11 comments

Losing a file's history when it's modified and renamed via an IDE or plain ol' mv (as opposed to git mv) is one of my biggest pain points with Git - it tries to detect the renaming, but sufficient content modifications seem to break its algorithm.

It's a bit of a case of the tail wagging the dog when you find yourself coding in a certain style to please a version control tool.

You can adjust Git's rename (and copy) sensitivity when using tools like diff, blame, and log. Git doesn't actually treat moves specially at all (even when you do git mv), each revision is (effectively) a simple snapshot of what all your bits were at that point in time.

Downside: It doesn't know what a rename is in your history and detects it at the point of use (that is, when you 'use' your history - e.g. when doing git log).

Upside: You can adjust what it thinks a rename is when you need to without changing anything, and if it gets better at detecting renames, you can benefit from that without having to rewrite history.

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.

I don't really see it is changing coding style to simply have the rename be a discrete commit. I've never had a problem where it didn't recognize a rename when I do this. Any further changes I want to make to the file come in subsequent commits.

> I don't really see it is changing coding style to simply have the rename be a discrete commit

Depends on your language, I guess. Changing a Java class name typically involves renaming a file. So if you're doing a refactor, where renaming a class may only be one of several changes you're making 'in the flow', you have to consciously pause after renaming that class and commit.

That would be nice, but handling of large binaries would be killer as well.

Barring some amazing breakthrough in data compression to the tune of P=NP, I just don't see how this problem could possibly be solved within the constraints of the "D" in "DVCS".

The best thing we have now is to centralise large binaries and to use specialised binary-diffing tools for handling their changes. As discussed in Lobsters[1], that's more or less how Facebook has handled this particular problem[2].

[1] https://lobste.rs/s/tekiod/unorthodocs_abandon_your_dvcs_and...

[2] http://mercurial.selenic.com/wiki/ScaleMercurial#Concern:_La...

Does git-annex[1] solve the large file problem? I know Gitlab suggested it as a solution.

[1] https://git-annex.branchable.com/

It does not solve the large file problem. It only changes the problem parameters so that a solution exists, by breaking the "D" in "DVCS".

Its interface is kind of ugly, though. I don't know if gitlab gave it a better interface.

The corresponding extension in Mercurial is largefiles, in case you still think there is room in the world for a DVCS other than git.

I'm pretty agnostic regarding scm, so long as I have lightweight branching and lots of tooling built with love.

I only use the basic functionality in git (eg. no submodules, central master repo), so I wouldn't notice the difference between Mercurial, Bazaar, etc and git.

Git may not be the best, but (probably because of Github) it is the winner in this generation.

I've never understood why you have to re-upload if you rename a folder in many systems. I've had git reupload huge assets folders after renamaming them, and the same happens with dropbox.

Reply on news.ycombinator.com