4 ms·
I think GP's point was that there is an argument that `git` should be able to track "real" metadata about what changed. e.g. `git mv foo bar` should be able to
by Karellen 3y ago
I think GP's point was that there is an argument that `git` should be able to track "real" metadata about what changed. e.g. `git mv foo bar` should be able to record that "foo" was definitely renamed to "bar" - even in the presence of massive changes. Whereas `git rm foo; git add bar` should be able to record that "foo" was deleted and "bar" was added, even if the files are substantially similar. And that this should be more meaningful to `git` itself than just hints in the commit message.
(Personally, I've not come across the need for such a feature. But I can understand why people might want to have it be available.)
- IshKebab 3y agoYeah it sounds nice in theory but the number of edge cases and complications it adds are crazy. * You need to add `git cp`. * You'll mess things up if you accidentally `mv` instead of `git mv`. * All IDEs have to add support for this. * Have fun resolving metadata merge conflicts! That's just the things I thought if in a few seconds. IMO the sensible way to improve this is to have a place for Git to add hints, so that it's automatic rename detection algorithms work better.
- forrestthewoods 3y agoI think you’re overcomplicating it. Files just need to know where they moved from, if anywhere. Copy, modify, delete operations can be auto-detected almost all of the time. Lineage can be edited after the fact if needed.
- erik_seaberg 3y agoIf you use “svn mv” inconsistently, you rapidly land in conflict resolution hell (this was a nearly weekly ordeal on a former team). If you forget to use “git mv,” git still works.