-10

I have 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 /timeline and /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 Log Notifications/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?

The explanation for Question has been edited, but not showing as such at https://meta.stackexchange.com/a/16820/163204 then means the "Edit Grace Period" ruins the Edit History functionality?

Improve this question
8
  • 1
    What is a commit message?
    – Nij
    Commented Jul 30, 2020 at 8:18
  • 2
    @Nij it's the edit summary one can type when submitting an edit.
    – Shadow Wizard
    Commented Jul 30, 2020 at 8:21
  • 3
    So, why are you not using the actual name for it? It is an edit summary - it summarises the purpose of the edit. "Commit message" makes no sense here.
    – Nij
    Commented Jul 30, 2020 at 8:23
  • 4
    @Nij "commit" is a programming term meaning you made changes to something, and you're committing those changes. When doing so, you can also add a message explaining what you changed. So using this to describe edits in Stack Exchange is fine, and does make sense.
    – Shadow Wizard
    Commented Jul 30, 2020 at 9:27
  • 6
    Does this answer your question? Take most recent (or concatenate) edit comments when editing during grace period
    – gnat
    Commented Jul 30, 2020 at 10:03
  • 9
    Eh, no, it doesn't, since the thing is called an edit summary and the user is clearly aware of this, and then mixes terminology throughout the question, making it confusing to follow (and since the gist of the feature request is excess work for pointless change, not worth deciphering further).
    – Nij
    Commented Jul 30, 2020 at 10:55
  • @Nij Well, at least that's not a bug but status-bydesign.
    – πάντα ῥεῖ
    Commented Jul 30, 2020 at 14:13
  • 2
    The grace period doesn't ruin the Edit history functionality. It is a great help as pointed out in the answers. Only thing here is that you were not aware of its workings and intended use. It might be better if you write a question and wait a day or two before posting it, then you might jnt need so many edits to your post.
    – Luuklag
    Commented Jul 31, 2020 at 10:00

2 Answers 2

Reset to default
9

This is very difficult to understand but I think I got your meaning here.

You are saying that when you made revision 10 to the example post, the text from the edit summery of your previous edit was automatically added to the text entry box for edit summaries and thus you didn't notice when writing the new summary so now your revision 10 has the text of both summaries?

This is not a bug but a feature. If you edit a post twice in quick succession the summary is automatically filled as quick successive edits tend to imply minor corrections that don't need new detailed summaries.

The simple solution is simply to delete that text when writing a new summary if you don't want it. It does not need a complicated solution as you suggest.

Improve this answer
3
  • The problem is the edits diff also does not associate to the correct message which is also difficult to understand. Also, you say Revision 10 but that was actually Revision ~12... that is impossible to use for evidence.
    – prosody-Gabe Vereable Context
    Commented Jul 30, 2020 at 9:19
  • 2
    An edit message will be automatically created indicating how many characters were modified. If another edit is made within the grace period of the first edit, that value will not be recalculated. Is that the problem you're describing? @prosody
    – Mast
    Commented Jul 30, 2020 at 9:30
  • @Mast Meaning the Broken Modified Character Count is parallel to Broken Modified/Diff View problem?
    – prosody-Gabe Vereable Context
    Commented Jul 30, 2020 at 9:33
9

You're supposed to try to consolidate your edits. It's not very efficient to make a series of small edits in rapid succession. And it's rather annoying for anyone who happens to be reading the post while you're making multiple edits to it.

Now it often happens that an editor notices an extra item to fix after they submitted the edit, even though they carefully checked the preview. So the system helps us by merging multiple edits made within the grace period. Such merged edits only need a single edit summary comment because they are considered logically as having occurred in a single editing session.

In your question, you refer to edit summaries as "commit messages". But a Stack Exchange post isn't a software project, and it doesn't require elaborate edit summaries. You should not edit a post by making a series of separate edits, each with its own detailed summary. Instead, try to change everything that needs changing in one go, and write a brief summary describing your changes. If you're editing your own posts, and you have important information that you wish to include in the edit summary, please consider if that information would be better in the body of the post instead.

Improve this answer
2
  • So the "bug by design" is a workaround for users who complain about Notifications? Or for Editing Efficiency then? I value Commit Messages as equal to Edit Summaries here.
    – prosody-Gabe Vereable Context
    Commented Jul 30, 2020 at 14:47
  • 4
    It's not a workaround, it's the intended usage, as this answer has already stated. Make all the edits at once, and summarise them in the summary.
    – Nij
    Commented Jul 31, 2020 at 23:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .