It's also pretty easy to find a set of patches that have to be applied in order. Then someone copies those patches onto another divergent tree, which has it's own set of custom patches without renaming. This is dangerous in git and probably sensible in pijul.
Haven't use pijul in practice, but it's not hard to imagine being better than git here.
It still required intelligence (changes across files may not be tracked as dependent but actually are) but it was a different experience from what git provides.
Fossil's implementation is the best, since a cherry-picked commit always points back to its origin.
How do you do this? With submodules / subtrees?
"This is a useless property because the graph is only encoded at the patch layer. In the real world you have far more semantic dependencies than patch dependencies. ie, I have a patch that adds a function that calls a function added in another patch. Pijul doesn't know about that."
Darcs solved this in two different ways.
1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.
2. Practicality. In reality, there's no scenario where someone is pulling your "use function X" patches and also not pulling the "define function X" patch. They could if they really want to, but this would be a lot of effort for a deliberately bad result. It would be like, in Git, cherry-picking the "use" patches without the "define" patches. In neither system would this happen by accident.
"Conflicts coming back is not an issue in git. For some reason people think they need to use rebase when they should almost always be using merge."
There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.
I deliberately moved away from Darcs after a few years - the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened. (Also branch discovery in Darcs basically doesn't exist; Pijul fixed this, at least!) I love Fossil and Mercurial for their adherence to accurate history.
I don't know who would want to put in the work of mapping out the semantic dependency graph because maybe some day someone might want to compose a slightly different set of patches. And even if everyone tried, it would surely still fail because that's so hard or impossible.
> There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.
Just stop using rebase is much easier to socialize than let's all move to Pijul. It's also the correct thing to do.
> the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened.
I strongly agree with this and think it's the only tractable way to operate.