6 ms·

What are those weak points and how does Anu fix them? I found a technical example in https://anu.dev/documentation/associativity.html https://anu.dev/documentat

What are those weak points and how does Anu fix them? I found a technical example in https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html, but it was unconvincing. In their example, three way merge should produce a conflict for a human to resolve it. Which is good, we don't want a 'smart' tool to do the wrong thing and silently introduce bugs. If the argument is that pijul/anu reduce the number of conflicts by exploiting history, is there a quantization of this benefit for practical workloads, e.g. popular git repos?

IshKebab 6y ago
I agree. Also in their example they lose a nice property of git - invariance to squashing. If Alice squashes her two changes then the final merge behaves differently to if she hadn't. Very confusing! Git definitely could be much smart about merge conflicts, but it's a hard research problem so I'm not surprised it isn't.
andolanra 6y ago
That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. But there are scenarios in which this avoids tedious human merges. Consider that I'm applying a series of patches which make changes in a file and later on walk those changes back, and run into a merge conflict there. In Git, I could squash those changes to avoid dealing with the conflict, but then I've lost history. I could apply the changes, skipping the relevant patches, but if those patches still contained useful work elsewhere, then I'd have to go in and resolve those problems manually. In contrast, this same scenario in Pijul and Anu would just trivially work in a way that didn't produce conflicts. I would apply the sequence of patches, and one patch would produce a conflict… but because they can keep doing work in the presence of conflicts, then they could keep applying subsequent patches and apply the patches which walk back the changes, and in that resolve the conflict automatically, but unlike the Git approach where I flattened the changes first, I would still have the full commit history associated with that sequence. Now, that doesn't mean that Pijul or Anu will automatically fix all merges. If you have two separate code edits to reconcile, you might still need a human in the loop to reconcile them. But the fact that they can keep making changes in the presence of conflicts allows them to avoid a certain kind of "busywork" that comes with managing git history.
- apostacy 6y ago
  > That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. I don't think it is really true that git requires you to fix conflicts before continuing. There are strategies that can let you emulate deferred merging. I rarely let merging hold me back. If I don't have time to merge into master, just do git push server master:synced/master.
  - ricardobeat 6y ago
    Git requires you to fix conflicts to continue in that branch, as commits will not have been applied until you resolve them. You can work around that, but the longer you postpone the harder it becomes to resolve them, and the result will depend on the order you decide to merge / rebase everything.
pmeunier 6y ago
No, 3-way merge does not produce a conflict in that case, nor shouldn't it. Alice adds lines at the very beginning of the file, Bob adds line at the end, and 3-way-merge merges Bob's lines into Alice's new line. That is incorrect and is not a conflict.
- alquemist 6y ago
  You are correct, thanks for the clarification. From https://www.gnu.org/software/diffutils/manual/diffutils.html#diff3-Merging https://www.gnu.org/software/diffutils/manual/diffutils.html... > You can think of this as subtracting older from yours and adding the result to mine, or as merging into mine the changes that would turn older into yours. The point stands: taking history in account is unconvincing, as it assumes intent where none is explicitly given. In the example, if the top branch had a single commit, AB => ABGAB, then there is no way to reliably infer that A 'intended' [+ABG]AB, vs. AB[+GAB]. Even with the given history, maybe the author of the top branch really intended AB => AB[+GAB], but made an error, corrected in the 2nd commit. The problem is fundamentally ambiguous. We can argue which of the diff3 or anu/pijul heuristics are better. In practice I suspect the difference is not that large. For completeness, here's a guess of what diff3 does, assuming merging top into bottom, following https://blog.jcoglan.com/2017/05/08/merging-with-diff3 https://blog.jcoglan.com/2017/05/08/merging-with-diff3. [bottom] => A [+X] B [top] => AB [+GAB] B O T A A A +X B B B +G +A +B Resulting in A[+X]B[+GAB] without conflicts.
pmeunier 6y ago
> Which is good, we don't want a 'smart' tool to do the wrong thing and silently introduce bugs Then that example you link means that you should stop using 3-way merge / git / svn / mercurial.
- alquemist 6y ago
  You are correct, there are no diff3 conflicts, thanks again for the clarification. The problem is fundamentally ambiguous, and the argument a bit more subtle. As a rule of thumb, when two heuristics are available, pick the simplest one (e.g. the one requiring fewer inputs), especially if a human needs to wrap their head around the rare cases where the heuristic goes wrong.
merijnv 6y ago
Lemme give you one example of one workflow I've encountered a bunch of times that's super annoying with git. I port/test a project to a new OS. I run into a bunch of issues, like linkers, environments, etc. that are broken that I need to fix. I try and make clean commits tackling one issue at a time, so we get 1 commit for the linker issues, 1 for the docs, 1 for the environment, etc. eventually I have 5 commits of fixes. These fixes are all orthogonal, so ideally I want to make separate PRs and separate reviews for them. But locally they're all tied together (in chronological order), since I need all of them there to continue development. In git I can either open 1 big PR including all fixes at once (annoying) or I can make a PR for one commit, wait until it's merged, then PR the next, etc. The only way to get them nicely separate is if I take all those 5 commits, rebase each of them onto master in its own branch and PR those 5 branches. But that ruins my ability to work locally. The associativity of (non-conflicting) patches in a patch based VCS like Anu/Pijul means that this "ordering" of patches doesn't exist. I have 5 patches you don't, I can PR each of them independently without needing to manipulate history or anything, because fundamentally the patches aren't related and therefore there's no reason for an ordering like the git DAG forces upon you. Of course this is a fairly niche (but hopefully concrete enough) example of how this enforced ordering of commits can actively harm workflows/collaboration.
- alquemist 6y ago
  Thanks for the example. History manipulation is a nono. While I'm not a git/diff3 expert, could one say 'make patch K from commit triple K0,K1,K2', meaning 'all changes between commits K1 and K2, with respect to origin K0', then make independent PRs out of them? Maybe will be only 95% correct, but that's what tests are for.
  - cutemonster 6y ago
    > History manipulation is a nono (He means on his private computer)
- gnufx 6y ago
  Yes, except that I don't think that's niche. With darcs, I have a collection of patches available from developments/contributions, and a release is a set I'm happy with on top of the previous release tag. If one of them causes trouble during testing, it can typically just be removed from the set. (Obviously it doesn't always work that cleanly, but it typically does.) When happy, tag and release. It's a pleasant model that's straightforward enough for someone who's only been maintaining large projects since the early days of networked CVS.

IshKebab 6y ago

I agree. Also in their example they lose a nice property of git - invariance to squashing. If Alice squashes her two changes then the final merge behaves differently to if she hadn't. Very confusing! Git definitely could be much smart about merge conflicts, but it's a hard research problem so I'm not surprised it isn't.

andolanra 6y ago

That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. But there are scenarios in which this avoids tedious human merges. Consider that I'm applying a series of patches which make changes in a file and later on walk those changes back, and run into a merge conflict there. In Git, I could squash those changes to avoid dealing with the conflict, but then I've lost history. I could apply the changes, skipping the relevant patches, but if those patches still contained useful work elsewhere, then I'd have to go in and resolve those problems manually. In contrast, this same scenario in Pijul and Anu would just trivially work in a way that didn't produce conflicts. I would apply the sequence of patches, and one patch would produce a conflict… but because they can keep doing work in the presence of conflicts, then they could keep applying subsequent patches and apply the patches which walk back the changes, and in that resolve the conflict automatically, but unlike the Git approach where I flattened the changes first, I would still have the full commit history associated with that sequence. Now, that doesn't mean that Pijul or Anu will automatically fix all merges. If you have two separate code edits to reconcile, you might still need a human in the loop to reconcile them. But the fact that they can keep making changes in the presence of conflicts allows them to avoid a certain kind of "busywork" that comes with managing git history.

apostacy 6y ago
> That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. I don't think it is really true that git requires you to fix conflicts before continuing. There are strategies that can let you emulate deferred merging. I rarely let merging hold me back. If I don't have time to merge into master, just do git push server master:synced/master.
- ricardobeat 6y ago
  Git requires you to fix conflicts to continue in that branch, as commits will not have been applied until you resolve them. You can work around that, but the longer you postpone the harder it becomes to resolve them, and the result will depend on the order you decide to merge / rebase everything.

pmeunier 6y ago

No, 3-way merge does not produce a conflict in that case, nor shouldn't it. Alice adds lines at the very beginning of the file, Bob adds line at the end, and 3-way-merge merges Bob's lines into Alice's new line. That is incorrect and is not a conflict.

alquemist 6y ago
You are correct, thanks for the clarification. From https://www.gnu.org/software/diffutils/manual/diffutils.html#diff3-Merging https://www.gnu.org/software/diffutils/manual/diffutils.html... > You can think of this as subtracting older from yours and adding the result to mine, or as merging into mine the changes that would turn older into yours. The point stands: taking history in account is unconvincing, as it assumes intent where none is explicitly given. In the example, if the top branch had a single commit, AB => ABGAB, then there is no way to reliably infer that A 'intended' [+ABG]AB, vs. AB[+GAB]. Even with the given history, maybe the author of the top branch really intended AB => AB[+GAB], but made an error, corrected in the 2nd commit. The problem is fundamentally ambiguous. We can argue which of the diff3 or anu/pijul heuristics are better. In practice I suspect the difference is not that large. For completeness, here's a guess of what diff3 does, assuming merging top into bottom, following https://blog.jcoglan.com/2017/05/08/merging-with-diff3 https://blog.jcoglan.com/2017/05/08/merging-with-diff3. [bottom] => A [+X] B [top] => AB [+GAB] B O T A A A +X B B B +G +A +B Resulting in A[+X]B[+GAB] without conflicts.

pmeunier 6y ago

> Which is good, we don't want a 'smart' tool to do the wrong thing and silently introduce bugs Then that example you link means that you should stop using 3-way merge / git / svn / mercurial.

alquemist 6y ago
You are correct, there are no diff3 conflicts, thanks again for the clarification. The problem is fundamentally ambiguous, and the argument a bit more subtle. As a rule of thumb, when two heuristics are available, pick the simplest one (e.g. the one requiring fewer inputs), especially if a human needs to wrap their head around the rare cases where the heuristic goes wrong.

merijnv 6y ago

Lemme give you one example of one workflow I've encountered a bunch of times that's super annoying with git. I port/test a project to a new OS. I run into a bunch of issues, like linkers, environments, etc. that are broken that I need to fix. I try and make clean commits tackling one issue at a time, so we get 1 commit for the linker issues, 1 for the docs, 1 for the environment, etc. eventually I have 5 commits of fixes. These fixes are all orthogonal, so ideally I want to make separate PRs and separate reviews for them. But locally they're all tied together (in chronological order), since I need all of them there to continue development. In git I can either open 1 big PR including all fixes at once (annoying) or I can make a PR for one commit, wait until it's merged, then PR the next, etc. The only way to get them nicely separate is if I take all those 5 commits, rebase each of them onto master in its own branch and PR those 5 branches. But that ruins my ability to work locally. The associativity of (non-conflicting) patches in a patch based VCS like Anu/Pijul means that this "ordering" of patches doesn't exist. I have 5 patches you don't, I can PR each of them independently without needing to manipulate history or anything, because fundamentally the patches aren't related and therefore there's no reason for an ordering like the git DAG forces upon you. Of course this is a fairly niche (but hopefully concrete enough) example of how this enforced ordering of commits can actively harm workflows/collaboration.

alquemist 6y ago
Thanks for the example. History manipulation is a nono. While I'm not a git/diff3 expert, could one say 'make patch K from commit triple K0,K1,K2', meaning 'all changes between commits K1 and K2, with respect to origin K0', then make independent PRs out of them? Maybe will be only 95% correct, but that's what tests are for.
- cutemonster 6y ago
  > History manipulation is a nono (He means on his private computer)
gnufx 6y ago
Yes, except that I don't think that's niche. With darcs, I have a collection of patches available from developments/contributions, and a release is a set I'm happy with on top of the previous release tag. If one of them causes trouble during testing, it can typically just be removed from the set. (Obviously it doesn't always work that cleanly, but it typically does.) When happy, tag and release. It's a pleasant model that's straightforward enough for someone who's only been maintaining large projects since the early days of networked CVS.