Patching patches


#1

Here is a feature that someone suggested to me today: patches that operate on other patches rather than on the direct text.

One potential implementation (but I have other ideas as well) could be to represent some patches as plain text files, added to the repository as normal files (for example in a patches directory at the top level), and patchable themselves. When a patch is patched, a cascade of unrecords + application of the new version would follow (the cascade is needed because this would obviously open the door to patches of patches of … of patches).

What do yous think?


#2

Intriguing. But are there real life use cases strong enough to justify the added complexity?

I was thinking: in github you can review commits and ask for changes; with pijul and this feature those changes would be made to the patch itself instead than as a new patch. Cleaner history when finally merged, but is it necessary in a patch-based system? One could just undo the patch, modify and record again.


#3

This comes from an actual real life use case (not for code though).


#4

I am sorry, but I don’t get the feature. The idea is that, when you patch a patch, this change the history? Like, sharable git commit --amend?


#5

Yes, I think so. I don’t know how big the difference would be between this, and the current implementation of this feature (which uses dependencies).

The use case is to keep two levels (patches to patches to the text) in the history, instead of one (patches to the text).


#6

To be honest, I don’t really see the point; and I fear it would make pijul more complex or confusing than necessary. But it may be because I can’t really get my head around this proposal.


#7

If you gonna implement it, please consider not patches of patches, but patches of all diffs graph and maybe, if storing code as AST is implemented, the graph of symbols in asts connected to each other with temporalmlinks. And why do we need metapatches? What is the use case?


#8

It’s an industrial use case, where people want to see their patches and patch them. I can’t say more for now, sorry, but I’ll hopefully announce it formally soon.


#9

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)


#10

Even though I am currently using primarily git for my development, I also have independently discovered an interesting use case for patches for patches, so I thought it might be worth sharing.

I am developing SIT (Serverless Information Tracker, http://sit.sh). SIT organizes all updates in an event sourcing way (each record is just a record of something that happened, to be processed by a reducer).

SIT’s first application is in issue tracking. One of its features is called “merge requests” – similar to pull requests on GitHub but self-contained, as in patches being included into those records. For trivial cases, this is perfectly fine, however, since there’s no way to “push-force” a new patch into the issue, only add a new version of it, in case of longer patches being discussed and worked on, I’d need to include that long patch every time I update it. As a potential solution for this problem, I’ve considered allowing recording a patch to a patch instead, potentially significantly reducing the need for duplicating the bulk of the patch being worked on.

Just my 2c!