Now that I’ve actually used pijul, receiving feedback from you and @lthms about the
tags command, I’m starting to see the usefulness of patching patches.
How I worked this time, when I received your feedback I’d just undo my patch, work on what needed changing, then recorded from scratch. Neat history, but the process to go there is lost. Even if we end up including discussions in the repo itself, the actual code reviewed is gone.
The other route would have been piling up patches. But this dirties history, unless we manually manage semantic dependencies (which is already possible in pijul, but honestly seems quite a bother; also, semantic deps are currently undistinguishable from automatic ones).
By patching patches, one could store both the reviews AND the reviewed patches in the history of the repo, maybe making them foldable when viewing the log. Which is so cool!
So, about the implementation, I don’t think we need to do anything too strange. Aren’t they just a subcase of semantic dependencies? the one in which the patches conflict so they must be applied in sequential order, solving conflicts automatically in favour of the younger one. Maybe this can be the occasion for deeply restructuring
show-dependencies. Semantic dependencies can either be: non-conflicting, basically a spontaneous branch; conflicting, basically patched patches (fixing a typo 2 years later, or similar things, belongs to this category too). Non-semantic dependencies are conflicting patches created “by chance” while working on different goals; their current implemention should work for patched patches too, the only difference is that in the latter, we tell pijul they are semantic. Though actually there is a subtle but important difference: semantic conflicts are applied to the initial patch, which remains the master; non-semantic conflicts overshadow the initial patch, becoming the new master.
In short, it seems it’s just a matter of changing the metadata field of dependencies to one which links to the related patches and explains their relationships (semantic non-conflicting, semantic conflicting, non-semantic conflicting)