Post changes are confusing because of tag relations

[faucetlol]

Long-known, but it seems like nobody's ever created an issue about this. It's a frequent cause of confusion, even among more experienced users, and is something that should eventually be addressed.

It makes tag changes painfully difficult to read, which is detrimental to patrolling recent tag changes for vandalism, which two tags did I actually add to the post below?

Creating post versions when tag relations are created is obviously not a feasible option, that will just flood the post changes database with junk data, but there must be a better solution than what we currently have.

See also

• topic #44053
• topic #44368
• topic #44568

[DonovanDMC]

I don't think there really is a better solution beyond either what we have now, or creating post versions when AIBUR are approved
Doing that naively would make an edit for every single entry on a BUR

In theory if the ids of every single edited post could be known after a BUR was done, you could do a superficial change (like adding a space to the tag string) to their tag strings to forcefully create a post version for the one approving the BUR

[Deer-Spangle]

In theory if the ids of every single edited post could be known after a BUR was done, you could do a superficial change (like adding a space to the tag string) to their tag strings to forcefully create a post version for the one approving the BUR

Isn't that literally what @faucetlol specifically warned against in the initial post?

Creating post versions when tag relations are created is obviously not a feasible option, that will just flood the post changes database with junk data

--

I have perhaps some dumb/naiive questions but might be handy for background for others:
Am I right that the tags displayed on a post is stored independently from the tag version history? Hence the issue here that they de-sync when relations are created.
In which case, couldn't additional fields be added to the post versions records which say which were automatically added as opposed to the manually changed ones, and then the UI could display them differently or even as separate virtual 'post version' entries in the table?
Even if it stored the before and after of each post version's tag list, then it would allow working out which were added manually (the difference between before and after) and which were done automatically (the difference between before and the previous version's after)
That would expand the size of the records, but wouldn't dramatically expand the number of post version entries in the database or anything, so wouldn't be nearly the same performance hit

I might be way off track, but hopefully a helpful perspective?

[faucetlol]

I don't think there really is a better solution beyond either what we have now, or creating post versions when AIBUR are approved

Well there's definitely a better way, it's just a matter of how difficult it will be to implement properly with what we've currently got. Maybe retrospectively fixing all the old changes is a lost cause, but making future edits more readable is a good enough achievement in itself.

A better solution could look something like this:

(compare to image in OP)

At first I thought it might be as easy as just omitting the implied tag from the added_tags field in the database if it already existed on the post but that field doesn't actually seem to be used for anything visually at all, the diff actually seems to just be calculated by the actual difference in the tags fields. It makes me wonder why added_tags and removed_tags fields are even there, I'm yet to actually take the time to properly have a look at the code.

---

Somewhat related: At some point Danbooru changed their post versions to only show the actual diffs (example) but I have no idea if they're still experiencing the same problem with AIBURs.