Totally agree on your main point though. The benefits of switching are far lower than the costs.
Once you understand this, GIT makes a whole lot more sense. The trouble with failed merges is an artifact of trying to appear like it tracks deltas. Merge conflicts when you're the only programmer on a product (but have multiple computers) are maddening.
I blew away .git and everything in it, restarting a repository, more than once because I couldn't resolve a merge conflict, before I learned that simple fact.
I've got from .zip files of my source code on floppy disks, to SVN, then Mercurial, and finally GIT. GIT is amazing, though the UI is a pain, as most agree.
But there is no machine-readable metadata that the commit is the same in both cases. In simple cases you can work around this by basing the patch off of the merge base but if there are conflicts that doesn't work well.
The result of this is that these two different but logically identically commits will cause future merge conflicts and make questions like "does this branch have this patch" much more difficult to answer.
This is something that I think https://pijul.org/ does quite well. Their base unit is a patch and that can be applied to multiple places. You can also have snapshots which are logically a collection of patches.
If you rename the file using git and that is the only change in your file, then it works:
git mv oldfile newfile
the tooling infers a rename based on the lack of a content change
Does nothing. Git won't remember you did it.
> and that is the only change in your file
This always works, but it means you need to choose between flaky rename detection and weird extra rename-only commits that probably don't compile.
I might be misremembering the technical details, but isn't that only the case in a git repo with zero pack files?
Will grant that the lack of metadata on renames can be issue when a file is heavily refactored alongside it's relocation.