-9

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?

  • 1
    What is a commit message? – Nij Jul 30 at 8:18
  • 2
    @Nij it's the edit summary one can type when submitting an edit. – Shadow 10 Years Wizard Jul 30 at 8:21
  • 2
    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 Jul 30 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 10 Years Wizard Jul 30 at 9:27
  • 6
    Does this answer your question? Take most recent (or concatenate) edit comments when editing during grace period – gnat Jul 30 at 10:03
  • 8
    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 Jul 30 at 10:55
  • @Nij Well, at least that's not a bug but status-bydesign. – πάντα ῥεῖ Jul 30 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 Jul 31 at 10:00
8

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 | |
  • 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-Gab Vereable Context Jul 30 at 9:19
  • 1
    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 Jul 30 at 9:30
  • @Mast Meaning the Broken Modified Character Count is parallel to Broken Modified/Diff View problem? – prosody-Gab Vereable Context Jul 30 at 9:33
8

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 | |
  • 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-Gab Vereable Context Jul 30 at 14:47
  • 2
    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 Jul 31 at 23:15
-8

It is (used as, and can be used as) a trick, which needs guidelines. If the coders involved are not willing to change interface behavior to follow convention/standards, then insofar ideally/pragmatically requiring/necessitating an (even just tooltip er alertbox style) interface/documentation change/addendum.

Normally in a "Version Control" system, the "expected behavior" is that One (1) Commit means One (1) Edit.

So first, some basic history (because not a single person here so far has mentioned they're aware or know the feature etymology/lineage, and I am being very patient as you can read).

Let me cite Stackexchange Co-Founder Spolsky theirself talking about Version Control, if being founder that maybe helps:

In 2010, software development author Joel Spolsky described distributed version control systems as "possibly the biggest advance in software development technology in the [past] ten years".4 https://en.wikipedia.org/wiki/Distributed_version_control (https://en.wikipedia.org/w/index.php?title=Distributed_version_control&oldid=955777812) quoting https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/ / https://web.archive.org/web/*/https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/

Know that, the way Joel set Edit Summary to work is mostly faithfully like a DVCS Commit Message (that would seem to be the/their intent and motive according to their just-quoted speaking, notably whilst albeit I am being openly attacked for asking about/using the/their word association), faithful to Git/Hg basically, with one strikingly officially undocumented change in behavior(!).

Knowing that, I am learning now how to adjust to the lack of documentation specifying the unusual/custom site program behavior, a rather suspicious user interface behavior for a programmer-centric site, which is not following the standard/convention used in other major/popular/Git/Hg Version Control systems (as much touted by our good leader Spolsky as being important to speak about).

I suggest: A tooltip or alertbox saying "You have 5 minutes in the current edit." would explain the actual behavior. Also, given the founding/foundational programming community here, maybe even homage to the fact succinctly/properly documenting it's setup to work exactly (in many if not most respects, with exact respect, even formally standardizable degrees of respect) like Git (and politely explaining the differential interface behavior), would Be Nice to the User.

That said, otherwise, maybe the current formal/informal advice, summarized from responses here, is: Attack the user for thinking it works like a Commit Message and Tell them "Do not edit so much with the text editor." and "Interrogate them again [from another account] about saying Commit Message." and Say "You're supposed to wait, even though it does not tell you." and "Do not write/edit at that speed, just change speed." (...even though the question has been asked ad nauseum before, implying the interface has an issue??)? That is not being a nice interface.

The words "Grace Period" (as suggested by others as terminology) are not anywhere so we're forcing users to guess. I had to pull teeth and have my teeth pulled to learn the ~~bug~~ feature was even called/"termed" a "Grace Period" semi-in/formally. I had to ask the question here to know the bug was a feature called a Grace Period, on a site deeply prided for writing (user-centric... or what did "Superuser.com" mean?) documentation.

"You have 1 minute in current Edit Summary." would be nice. A static/dynamic counter, or at least a static message explaining it's, um, unique, behavior. (If somebody I mean someapp/someappy started just setting their own time for things and not expressing their behavior in English words first, I would be and am startled. That kind of "unique behavior" is not acceptable coming from a leader like Spolsky who is a programmer role model in being a faithful and evangelical Git Advocate, and that kind of "unique behavior" is not acceptable for a user interface.)

If the feature is a not a trick then why not explain to the user, and be nice interface?

"You have 20 seconds (Grade Period) in current Edit Summary." would be nice. Some warning, indication, advice, words while editing (and properly labeled at /revisions, for documental researchers who need viable timestamps, and who might perhaps reasonably think the site written by DVCS advocate Joel Spolsky would follow Git protocols) explaining the interface behavior in English would be nice.

| improve this answer | |
  • I asked meta.stackexchange.com/questions/354326/… to help document the terminology used by the interface in question. – prosody-Gab Vereable Context Sep 18 at 15:12
  • We all got your point from the question, but apparently we don't agree. There is no need to write this rant disguised as an answer. – Luuklag Sep 24 at 7:13
  • @Luuklag My answer is valid (even if you want to state your personal opinion in response to reading me as somehow weighing my validity), your attack (or would you call that 'attack disguised as a comment') is noted. Do you have any specific writing about what I actually wrote or do you just want to vote and then tell me your reason for voting, because I read nothing about what I wrote in your response, I do not read a single keyword I actually used, definitely none of the letters I wrote in the order I used to form a word even cited once, by your esteemed review of my writing, equaling attack. – prosody-Gab Vereable Context Sep 24 at 15:29

You must log in to answer this question.

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