4 ms·

> I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file,… This is somewhat

> I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file,… This is somewhat contradictory. Of course, everybody works on states. But as you write yourself, you make changes to a file, you don't create a full new version from scratch every time you add a semicolon. So, if you "make changes", you actually do "work on diffs". > Further, diffs only make sense if you have the full version of the files, pre-diff. Without that full file state, diffs could operate in all sorts of incorrect ways. That actually is an argument against Git: because Git doesn't model diffs, yet tries to simulate them, Git merges and rebases do all sort of incorrect things. For example, even the following simple example is not correctly handled in Git: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html (see the figure "git merge vs pijul merge").

epistasis 6y ago
I do create an entirely new state with every single semicolon, and my text editor agrees in the way that it allows me to undo and redo. As an implementation detail, these are likely stored as diffs, but since the diff is from a known start or final point, it works out OK. When we start talking about diffs that operate on different files, then everything falls apart. Which is why I disagree heavily with the example pijul merge you linked. Since lines AB are copied directly in one edit, and the other edit adds a line X after AB, why does pijul decide that the correct merge is only adding the X line after the second instance of AB? Viewing this in terms of diffs instead of states means that everything is ambiguous rather than clear. What does it mean to do a diff on a diff? There are many definitions and few programmers will agree on what the proper algebraic operations are, and in fact the same person will often want different algebraic operations in different settings. In the example above, if X is a necessary cleanup step after invoking AB (e.g a file close after file open and read), then pijul's interpretation of the ambiguous situation is wrong. But if X is a summary step that's necessary only once after the double invocation of AB, (e.g. sum += read(); n += 1;) and X is, for example, mean = sum / n, then only one X is needed. Thinking about a "diff" without tying it to a full and complete starting state will always lead to these sorts of foundational problems, and it is quite clear from this pijul example that they haven't really thought about the problem much.
- pmeunier 6y ago
  > why does pijul decide that the correct merge is only adding the X line after the second instance of AB? It doesn't decide, it only guarantees that the order between lines is preserved in all cases. Also, since you seem to have "thought a lot about the problem", you probably noticed that what Git does is totally wrong, since what it does depends on whether you merge both commits at once, or one at a time! > the same person will often want different algebraic operations in different settings. I doubt that when Alice adds line at the top of the file, while Bob edits the bottom of the file, anyone would ever want Bob's new lines merged in the middle of Alice's new lines. Yet, that is what Git does. > it is quite clear from this pijul example that they haven't really thought about the problem much. Or maybe they have, and they have thought enough about it to notice that 3-way merge is doing the wrong thing, and that trying to merge snapshot doesn't even make any sense. They might have also thought enough about Git to understand that rebase is turning commits into patches, one by one, in order to "replay them on top of the current version". While I do agree that full versions are important for storage (and all version control systems, including patch-based ones, are able to recover full versions), they are not very useful to merge work, or to solve conflicts.

epistasis 6y ago

I do create an entirely new state with every single semicolon, and my text editor agrees in the way that it allows me to undo and redo. As an implementation detail, these are likely stored as diffs, but since the diff is from a known start or final point, it works out OK. When we start talking about diffs that operate on different files, then everything falls apart. Which is why I disagree heavily with the example pijul merge you linked. Since lines AB are copied directly in one edit, and the other edit adds a line X after AB, why does pijul decide that the correct merge is only adding the X line after the second instance of AB? Viewing this in terms of diffs instead of states means that everything is ambiguous rather than clear. What does it mean to do a diff on a diff? There are many definitions and few programmers will agree on what the proper algebraic operations are, and in fact the same person will often want different algebraic operations in different settings. In the example above, if X is a necessary cleanup step after invoking AB (e.g a file close after file open and read), then pijul's interpretation of the ambiguous situation is wrong. But if X is a summary step that's necessary only once after the double invocation of AB, (e.g. sum += read(); n += 1;) and X is, for example, mean = sum / n, then only one X is needed. Thinking about a "diff" without tying it to a full and complete starting state will always lead to these sorts of foundational problems, and it is quite clear from this pijul example that they haven't really thought about the problem much.

pmeunier 6y ago
> why does pijul decide that the correct merge is only adding the X line after the second instance of AB? It doesn't decide, it only guarantees that the order between lines is preserved in all cases. Also, since you seem to have "thought a lot about the problem", you probably noticed that what Git does is totally wrong, since what it does depends on whether you merge both commits at once, or one at a time! > the same person will often want different algebraic operations in different settings. I doubt that when Alice adds line at the top of the file, while Bob edits the bottom of the file, anyone would ever want Bob's new lines merged in the middle of Alice's new lines. Yet, that is what Git does. > it is quite clear from this pijul example that they haven't really thought about the problem much. Or maybe they have, and they have thought enough about it to notice that 3-way merge is doing the wrong thing, and that trying to merge snapshot doesn't even make any sense. They might have also thought enough about Git to understand that rebase is turning commits into patches, one by one, in order to "replay them on top of the current version". While I do agree that full versions are important for storage (and all version control systems, including patch-based ones, are able to recover full versions), they are not very useful to merge work, or to solve conflicts.