So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be ordered in more arbitrary ways. On the other hand Git is snapshot-based. And Git was built for the Linux Kernel (specifically from the perspective of the lead maintainer). But my impression from the outside is that the Linux Kernel development is very “patch-based”. First of all in the sense of sending patches via email. But also in the sense that these patches can be applied to multiple trees (not just the Linus tree) and different subsystems have to cherry-pick commits (i.e. picking a commit and applying it as a patch, creating a new commit somewhere else). And it seems that people are concerned about tracking what patches are where, what commit (which can correspond to many commits according to cherry-picks) fixes whatever commit. The people behind Patchwork (a tool for maintainers which tracks patch series) is concerned about being able to track patches; the usual `git patch-id`, naming heuristics, etc. does not seem good enough.
And as patches go through different contributors and maintainers they accumulate trailers in the form of signed-off-by and things like that. Even non-trailer (not key-value line) changelogs like: `[: fixed typo/ fixed off by one]`. And if the change is in the code then the patch content changes (not just the commit message).
The Git project is also pretty patch-based in its development. Even for those who only cares about the maintainer tree: these patches apply to this other in-flight patch series; this diff here can be applied on top of your pending patch series; this patch series is from our ongoing work at Gitlab (company); I’m resending this patch series that X did three months ago but seemed to have abandoned; etc.