Hacker News Reader

Comment by smcameron | Hacker News Reader

On the flip side, reorganizing a codebase totally fucks the git history.

Just make sure to use 'git mv' for all your files so the history can be tracked. 'git log myfile' will only show the history for that file, but 'git blame' will follow the line changes across file moves.

That aside, there are some many productivity and tooling gains around organizing your project properly, that it is worth history discontinuities.

Also, I've found that the worse the project organization is, the less likely the team is to separate out different fileset changes into different commits to keep a useful history, or make the use of the git history at all outside of looking at a few recent commits or or sometimes looking at the last release. I've heard this as very circular arguments. Can't re-org because we loose history. Can't maintain good history because the project is too disorganized.

Has behavior for `git mv` changed? Last time I investigated, the command was convenience to `git add` after a `mv` with a single command. Git doesn't actually explicitly track renames, it leverages some sort of auto-detection based on file content similarity.

Still good to use the command, just keep in mind git isn't really treating it any different than a normal `mv` followed by `git add`.

https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...

This might not be the forum for it, but I have a question about this - I thought git was supposed to be pretty smart about detecting renames, but in my experience (on Windows) it never does, and I always have to use `git mv`. What's the deal with this?

Even if rename detection is enabled, git will only try to identify renames if it wouldn't take too much time (since IIRC it's a O(#files^2) operation).

Thus, there's a config "diff.renameLimit" and "merge.renameLimit" that tells git to only detect renames if less than N files are affected.

I have personally been burned by this before, and there usually is a default value set in most git clients.

See also some discussion at https://stackoverflow.com/a/7831027/1237375 .

It does work, check what happens after you git add it all, not before.

'git log --follow' should try and log following back through the rename. It can be a bit slow with big repositories though.

If you do it all in one swoop it's not too bad. The difficult part is managing everyone's "perfect structure".

hg move $thing. I’m bummed git “won”

I think you can find edge cases in either tool where the data exists to make something work, but the data model doesn't allow it.

Consider a file like "package foobar; func DoFoo() { ... }; func DoBar() { ... }". You then refactor that to two packages, "package foo; func Do() { ... }" "package bar; func Do() { ... }". The body of foobar.DoFoo is identical to foo.Do, but no version control system I've ever used will move the history of that function body to the new location.

I guess what I'm saying that tracking renames as a first-class object is nice, but it still doesn't represent many types of refactorings. To smugly declare perfection, a version control system should probably have that feature, because it is a relatively common refactoring.

Of course a tool that tracks the history of file changes doesn’t do your example. That’s not an edge case, it’s a flawed argument contrived to try and make a point, albeit poorly.

`git mv` also exists.

Reply on news.ycombinator.com