The issue is that `log` orders the patches by when they were made, not by when they were merged (in reality it might be a bit more detailed, probably a patch wi

The issue is that `log` orders the patches by when they were made, not by when they were merged (in reality it might be a bit more detailed, probably a patch will always be ordered after the patches it depends on). git log also has parameters to configure it in that fashion, and it's also what github uses. However, importantly, git bisect does not use it. It uses the DAG of commits that git maintains. Yes, also git also only has a weak notion of a history of a branch: it is somewhat inside the titles of merge commits, and merge commits also have an order of their parents, so often you can just walk the first parent and always get to commits that used to be state of the master branch at a specific point in time. Sometimes it's even easier when merged PRs get squashed. But yeah, it's a bit implicit and if you e.g. rebase a PR then some of the commits in it have never been the tip of the master branch. But very importantly, every commit in git depends on every single commit that has contributed to that commit's tree. In pijul, they break up that property, and patches only depend on those patches which have directly modified the pieces of code that the change is editing. IIRC you can also manually introduce dependencies but those are rare. There isn't even a notion of a "patch's tree". You could construct a branch with only the patch and its dependencies but probably that wouldn't compile, and it will definitely not reflect the state of the branch at that point in time. You can make new branches in pijul that you don't modify and use like tags, but it is an explicitly requested thing. I mean, I see the elegance in pijul. Reverting a patch that has no conflicts and un-reverting it is trivial. But on the other hand, how often do you do that? Some workflows need patch based thinking, others need snapshot based thinking, and VCS tools need to master both, whether they start out with a snapshot history (like git) and then build diff based workflows on it (diff, rebase, etc), or whether they start out with a patch tree, and then build snapshot based workflows on it. pijul has weak snapshot based workflows, this part is still missing.