Let me try to present one problem relating to cherry-picking. I don't know Pijul so I'm not sure it illustrates its strength clearly, but at the very least it

Let me try to present one problem relating to cherry-picking. I don't know Pijul so I'm not sure it illustrates its strength clearly, but at the very least it should address the idea that there is no problem with cherry-picking. Using git terminology here. Say you have a release branch and a master branch, and you normally fix bugs on the release branch and then merge the release branch into master. Now it happens that a bug was fixed in master, and later it turns out that it's actually a critical thing that should be fixed on the release branch, too. So you cherry-pick that fix into the release branch. Now the next time you merge from release into master, you attempt to merge this commit that was originally cherry-picked from master, so it's already present in master. But git doesn't know. With some luck, git sees that the textual change is already present, but I believe that can also fail sometimes. With Pijul, you would have applied the patch from the release branch onto the master branch, and Pijul would have recorded that, and on the next merge from release to master, Pijul knows to skip this patch. Another place where Pijul helps is when cherry-picking the bugfix in the first place: Suppose the bugfix includes calling some function (procedure, method), but another (earlier) change on master has renamed that function. Then Pijul can alert you to this fact and tell you which other commit (patch) from master is needed to cleanly apply the bugfix. Does this help?