| > It's certainly possibly I got some information wrong about Pijul. Please correct me if I have! That's actually the case, because you can totally simulate Git using Pijul if you want, except for the weird merges where Git shuffles up lines randomly. > This is a big drawback and so we should hope to get some serious benefits to make up for it. It is not a drawback at all, there are no downsides to it, and we get the very serious benefit that merges are associative, which is not the case in Git. Indeed, in Git (using diff3 to merge), when Alice adds lines at the beginning of a file and Bob adds lines at the end, some of Bob's line can get merged into Alice's new lines. > it can not track things like "This calls a function introduced in patch X" which makes the cherry-picking functionality of very little value. You can totally do that in Pijul by adding extra dependencies, and moreover, this is like saying `git rebase` adds very little value to Git. > Pijul is like rebase in that it forces you to consider the full history of all the patches in a set which requires to resolve arbitrary conflicts It is actually the exact opposite: Git forces you to reconsider those conflicts (there's even `git rerere`), whereas Pijul only shows you the unresolved conflicts. Once a conflict is solved in Pijul, it's solved by a patch, and solved forever. |
I don't think this is true. The snapshot model is fundamentally different and doesn't require resolving conflicts in the same way.
> It is not a drawback at all, there are no downsides to it
It's a much more complicated model to implement, performance isn't as good, and your model is closely tied to your diffing algorithm. Contrast this to git where you can merge however you want and no one else needs to know the details.
> You can totally do that in Pijul by adding extra dependencies, and moreover, this is like saying `git rebase` adds very little value to Git.
Can do that and will happen in practice are very different things. It's not something likely possible to do automatically and doing it manually is just extra work that is probably for nothing.
> It is actually the exact opposite: Git forces you to reconsider those conflicts (there's even `git rerere`), whereas Pijul only shows you the unresolved conflicts. Once a conflict is solved in Pijul, it's solved by a patch, and solved forever.
I'm comparing git merge to adding a patch to a set in Pijul.
Let's say I have a patch A that adds a line: return 1 + 1 + 1 + 1;
and a patch B based upon A changes it to: return 1 + 1 + 2;
and a patch C based upon B changes that to: return 1 + 3;
and a patch D based upon the original A changes it to: return 4;
So we now have:
Now lets say we add them all to the same set of patches. Will I have to resolve the conflict in B and D and then also the conflict in (the resolution of B and D) and C?