| > 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. 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: A
|\
B D
|
C
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? |