Commit Messages ("Edit Summaries") that are describing other edits. The U.I. does not inform the user at all how the edit will be saved with previous/next commit message (maybe give a warning "Will Show As Same Edit for 5 minutes... 4 minutes..." and ask "Keep Same Commit Message?").
As of 2020.07 for https://law.stackexchange.com/posts/52986/revisions my most recent experience with the example error, I have a commit message from a previous edit for another completely separate edit and there is zero indication (or indicator) that is happening. Why are the database fields for separate edits being merged under other commit messages?
The problem is the edits diff also does not associate to the correct message, which is also difficult to understand. Revisions are not counted, which is impossible to use for evidence.
Diff function does not show what was diffed per Revision specified.
There is zero correlation between some edits shown and the Edit Summary shown, reading the history would be of zero value (for evidence there is not any ability to determine the actual edits/order per message), given current interface behavior that gives a terrible user experience.
Revision counts are completely not accurate, and diff views do not show the actual changes.
If the functionality of the
/revisions logs is to preserve the actual submission(s), then there should be some indication why it is not working as a factual/faithful audit trail. (Even if some users complain that log entries send push notification. Which might prescribe/require reprogramming Notifications, and not nullifying the value of the audit log in order to fix Notifications. We fixed a trigger by solving another probem, and created another problem. Can we trace the root of the actual problem being the
Log OR the
Notifications of the Log?)
If a "bug by design", is there a question or feature list where the specific function is described clearly? Is it a workaround for users who complain about Notifications, to ruin the auditability of the Edit Log?