Those reasons make sense. Would it be fair to summarize all that as "better merging with fewer merge conflicts"?
Git certainly has some room to improve in the merge conflict department. I looked at the bad merge example you posted -- I suspect I've hit that before. It's rare, but yeah it's there.
I also frequently notice that git complains about merge conflicts, while the custom diff tool I use to resolve them says there's no conflict, and I don't actually have to do anything. Good reason to use a custom merge tool with git.
But, given all this, is this really all an outcome of patches vs snapshots, or is this just git's merge algorithm being suboptimal? Certainly git could selectively ignore the DAG when merging, couldn't it? Even after reading the other comments here, it still seems to me like git has more information when merging than the "patch-based" workflow of darcs & Pijul.
It seems to me like there's a language problem with trying to draw a distinction between patches and snapshots. Git is still storing and transferring patches at the tree level, even if it's not happening at the file level. Git does not store a commit as a zip snapshot of the entire tree, the commit is still only the changed files. It would be fair (but not standard or common) to call the overlay of changed files a "patch" or a "diff". People do still use git format-patch, and email git "patches" to each other. So it's inherently confusing & problematic to talk about git and say that it doesn't use patches.
What does make sense to me is the distinction of having a strict DAG vs not having one -- is that actually what people mean when they talk about snapshots vs patches? Am I tripping on it because I'm being too pedantic about what a "patch" is?
Right, the raw representations are convertible (at some point a patch-oriented darcs/pijul has to build a snapshot so that it can build a working tree; at various times you want to see the diffs in git or format a patch file to email). It does have more to do with the representation of change context both between patches (strict DAG versus algebraic sets with looser change context models), and even to some extent within a patch (in a classic diff the tools use hardcoded line numbers; in something like darcs/pijul even the line numbers of a patch aren't necessarily taken as a given and are a part of the context of the change).
