API/CLI to know what changed in the commit

[aguschin]

Question from @Suor

Is there a way to know whether model were added or removed/deprecated in a particular commit or in a checked out commit? Or better is it possible to list all such changes for a commit?

[Suor]

This might be not be relevant anymore. The logic around list all tags and decipher them with .check_ref() will work with new version registering I suppose.

[Suor]

Do we need to follow added to artifacts.yaml event still though?

[aguschin]

Do we need to follow added to artifacts.yaml event still though?

Yes, I think we should show them in some form. For registered/promoted version for sure, but you can get them with check-ref already. What about all other commits, I'm not sure. There will be a lot of commits that doesn't change artifacts.yaml at all - would be strange to show all of them. But:

1. If artifacts.yaml was changed at some point, sometimes it could be good to see the change. (i.e. in GTO enrichment)
2. If other enrichments changed (DVC or MLEM) it would be also beneficial to see these changes.

On the other hand, MLEM and DVC extensions don't work, seeing only GTO enrichment change is not that useful.

cc @dmpetrov

[Suor]

I would say if you added or changed description or changed filepath then it's useful to see that.

[aguschin]

filter out model events from commits with no changes to a particular model

It would be great if we could have changes for each commit in commit index for RepoIndexManager from GTO. cc. @aguschin

Originally posted by @amritghimire in https://github.com/iterative/studio/issues/3727#issuecomment-1149519488

[aguschin]

We also had a discussion with @amritghimire about this, posting here for visibility:

[omesser]

@amritghimire / @aguschin several things here:

1. structure - sounds like you're reinventing jsonpatch. Please take a look if that works and we can just stick to jsonpatch semantics

2. In case of multiple parent commits the changes / diffs section will need to create multiple sets of changes, each relating to different parent so maybe:

{
   "changes": {
     "<commit-sha1>": { "patch": [<jsonpatch-op1>, <jsonpatch-op2>, ...] },
     "<commit-sha2>": { "patch": [<jsonpatch-op1>, <jsonpatch-op2>, ...] }
     ...
   }
}