When you prepare a patch against a version control repo, usually there’s a round of reviews, in which you get review comments on your patch, then you send a new version, get review again etc. until the patch is (hopefully) ready and accepted and applied to the repo.
In Merge Requests, it happens similarly: You can force-push to rewrite your commits, and people can comment on the new code you committed. The old comments on the old diff are still available.
Before I took patch versions into account, I imagined a representation like this: A merge request is a Ticket
object (think of it as a Note
if Ticket
confuses you), with an attachment
of type Patch
.
I asked myself how to replace that one Patch
object with a set of versions. Since the order matters, and since the attachment
property doesn’t have "@container": "@list"
(i.e. its range isn’t an RDF ordered list), the way to represent an ordered list would be OrderedCollection
. Imagine a Ticket
or Note
or whatever, in which attachment
is an OrderedCollection
of objects of type Patch
, or maybe even just the ID URIs. Then I thought, would that be weird for ActivityPub implementations, to understand what the attachment is? They may have to figure out it’s an OrderedCollection
, look at the items
, HTTP GET one of them, discover its type is Patch
, and then they can say “oh it’s a collection of patches” and either “Idk what to do with this, ignoring” or “let’s tell the user about this stuff”.
What do you think?
Another option is to use a custom dedicated property e.g. patch
instead of attachment
. But I prefer not to, if the merge request is represented as a TIcket
. If it gets represented as a Merge
or MergeRequest
or Offer
or something like that, then perhaps the collection of patches could be the object
of that thing.