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.