3 ms·

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

by smcameron 6y ago

el_dev_hell 6y ago
If you do it all in one swoop it's not too bad. The difficult part is managing everyone's "perfect structure".
irishcoffee 6y ago
hg move $thing. I’m bummed git “won”
- filleduchaos 6y ago
  `git mv` also exists.
- jrockway 6y ago
  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.
  - irishcoffee 6y ago
    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.
vimax 6y ago
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.
- nlawalker 6y ago
  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?
  - hrydgard 6y ago
    It does work, check what happens after you git add it all, not before.
  - ThePadawan 6y ago
    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 https://stackoverflow.com/a/7831027/1237375 .
- jrib 6y ago
  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_not_.22track.22_renames.3F https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...

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

el_dev_hell 6y ago

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

irishcoffee 6y ago

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

filleduchaos 6y ago
`git mv` also exists.
jrockway 6y ago
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.
- irishcoffee 6y ago
  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.

vimax 6y ago

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.

nlawalker 6y ago
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?
- hrydgard 6y ago
  It does work, check what happens after you git add it all, not before.
- ThePadawan 6y ago
  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 https://stackoverflow.com/a/7831027/1237375 .
jrib 6y ago
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_not_.22track.22_renames.3F https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...