[chriswarbo]

Merging is only one aspect of version control. Also, merging (especially automatically) is limited by the quality of the data. For example, it's common for git to mix up function definitions by fixating on common lines (e.g. braces), e.g.

    -def foo()
    -{
    +def bar()
    +{
    +  doBarThing;
    -  doFooThing;
     }

There are many ways to represent the same diff, but this sort of half-and-half result happens so often, and is such a minor problem, that it's usually not worth bothering to fix when committing. Yet it's the sort of weird input that can complicate later merges, cherry-picking, etc.

A semantic-aware diff could do better. Again, there are many ways to represent the diff, but it could be as fine-grained as the token-level, e.g.

    def -foo+bar()
    {
      -doFooThing+doBarThing;
    }

Or as coarse-grained as the definition level, e.g.

    -def foo()
    -{
    -  doFooThing;
    -}
    +def bar()
    +{
    +  doBarThing;
    +}

Either way (or something in-between), these represent more meaningful changes, and hence provide more useful input to subsequent processing (e.g. merging).

[waterofclear]

I'm not sure what you mean. Git is snapshot based. There is nothing to fix when committing, you just commit the result of the merge. Any diff you see is just for display purposes or for input to the three-way merge algorithm. Other users might see a different result if they "git show" your commit if they have a different diff algorithm configured. Pijul is not immune from diff algorithm problems you are talking about except with Pijul it is part of the repo encoding unlike Git. IOW, git already has the freedom to use a merging strategy that understands tokens or AST since it is not hard-coded into the repo encoding.