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.
Comments
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.