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
Ticket confuses you), with an
attachment of type
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
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
Offer or something like that, then perhaps the collection of patches could be the
object of that thing.