The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git.
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.
Not only merge conflicts I find that this causes trouble if you need to manage multiple branches. Generally you see patterns like 1. Create patch 2. Merge to main branch 3. Backport a cherry pick.
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.
`git mv` is just shorthand for `git rm` and `git add`. All Git knows is that there was a file called `oldfile` and there's now a file called `newfile`, and whether or not they have similar contents or filenames. It's only when you run `git status` or `git diff` or whatever that it actually tries to guess if anything was renamed. So what you're seeing isn't the rename being recorded in history but just that guess being correct. It's easy for it to become incorrect if you make some nontrivial changes or have multiple similar files.
The parent comment's suggestion is to commit each of these moves individually, which should guarantee that the detection algorithm will get it right. Will definitely pollute your history, though.
Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.
Totally agree on your main point though. The benefits of switching are far lower than the costs.