I'm having a pretty big problem with the way the editing system is working lately. I think it was a recent change, but there no longer appears to be a warning message when another user has edited the same question you're in the process of editing. Instead, you're blocked from posting your revision at the same time.

This is a big problem for people like me, who tend to go "the whole hog" when editing and make several of the following changes at once;

  • improve the title;
  • fix the spelling/grammar;
  • add code indentation;
  • add/remove tags;
  • add code formatting HTML comments;
  • removing hellos and thank yous and signatures

The problem is that doing all of this takes too much time, and almost always someone else comes along and does only one of those things. It's really frustrating — almost to the point where I feel like not improving new questions as they come along.

Can we get some kind of merge feature, or even something similar to the "approve edits" where you get to preview the other edit and at least decide whether yours is better or not? There could even be an option to close this preview box and improve your own edit so that it includes both sets of changes (if an auto merge will be too difficult).

  • 6
    +1, excellent suggestion
    – Johan
    Commented May 30, 2011 at 10:48
  • 14
    My own approach is to fully edit everything, then ctrl+a/ctrl+c the question. Submitting the question to find there are other edits isn't so much of a problem, then, since you can simply re-edit and ctrl+v. Though you do have to re-edit the title and tags. Which can be a nuisance. But +1 for the feature request. Commented May 30, 2011 at 10:50
  • I use Lazarus, which is actually an addon which for autosaving & recovering form information, as a means to hold the last entered data. But you do have a point Commented May 30, 2011 at 11:16
  • 1
    @David: that's pretty much what I'm doing at the moment, but it's rather frustrating that I have to do that.
    – Andy E
    Commented May 30, 2011 at 11:38
  • 5
    A related problem with the current system is that if five people are editing at once, it's an instant wiki. meta.stackexchange.com/questions/46078/…
    – mmyers
    Commented May 30, 2011 at 15:11
  • " there no longer appears to be a warning message when another user has edited the same question" -- this is definitely not the case ... I just tested it over and over again
    – waffles
    Commented May 31, 2011 at 4:42
  • aaaaarrrrrr ggggggghhhhhhh, so instead they get free rep instead of first being formally rejected... Commented Jun 11, 2011 at 7:44

5 Answers 5


This is what I just implemented, which may or may not have some gaps.

  • We still display a warning if somebody edited the post while you were editing, the new copy is: This post has been edited {0} time{1} since you began. Your edit can only be saved if it is more thorough than the currently saved edit.

  • When you try to save your edit we attempt to perform all the trivial merges (eg: you edited tags, they edited title) if they go through we save silently.

  • If there is a clash on body, we check how big your edit was and how big the previous edit was.

At the moment this is the algorithm ... it is totally subject to change:

if (curDiff + 25  > newDiff)
   errorFields.Add("{0} already edited the body of this post; your edit must be more substantive to override the current edit.");
  • If your edit is bigger than the previous edit by a certain margin it will be let through, when it overrides silently we log.

  • This logging is key, we will be monitoring it over the next few days and based on the data decide how to adjust the workflow and algorithm.

  • For example: if we find that lots of people are missing out on good tiny edits cause of the new system we may add a UI that notifies you of the change allows you to work it in your edit.

This new system heavily favo[u]rs substantive edits. There are a few side-effects but we will be measuring them.

  • 7
    Er... why not use diff to try to merge both changes to the post body? Commented Jun 1, 2011 at 6:59
  • Oh thank you thank you thank you. While some magic merging might be possible (and maybe in the end desirable), I hope this new magic will be Good Enough. :D
    – sarnold
    Commented Jun 10, 2011 at 20:23
  • Curious: upon overriding, did you consider something like infoFields.Add("{0} also edited the body of this post, but your edit was more substantial and was saved overriding the earlier edits.")?
    – Arjan
    Commented Oct 2, 2011 at 10:51
  • Sorry to bother you with this but it may need a looking at again. stackoverflow.com/suggested-edits/139388. This suggested edit passed through the cracks since it "removed" inconsequential whitespace from the previous revision. The original post linked to some code. The first edit had already added the code in. The suggestion "readded" it. Commented Nov 19, 2011 at 21:33
  • 1
    As for silently overwriting something, and the little fight, err, confusion this can cause in comments, see also: Bug in edit history associated with initial answer phase (non-recorded).
    – Arjan
    Commented Dec 18, 2011 at 19:36
  • Just in case it's different: edits in the grace period might be silently overwritten too, if someone else edits before the grace period is over. (Like the 1st bullet in these revisions, where I added "on Server Fault" within the grace period, which was lost when Cody/The Establishment posted an edit.)
    – Arjan
    Commented Mar 25, 2012 at 11:38
  • 1
    Hey @waffles, some edits are being considered much more substantive than others when they probably shouldn't (IMHO), particularly those that merely adds link(s) to a post. It's what happened here. I discussed it here with some others. I think this needs to be corrected. A merge may have been the better choice in this situation. Commented Apr 9, 2012 at 3:16

I agree that we could do better.

A few ideas:

  • Display a list of who else is editing the post if they are editing concurrently. (really like this)
  • Automatically handle non-conflicting merges (this is tricky, we would have a sophisticated merge engine or shell out)
  • Allow users to check out a file for editing with a timeout - dislike this as it makes it too easy to block. Even with timeouts and what-not.

As it stands, even with the current change I added I still feel we fall short instructing people how to deal with conflict. We display a big fat red banner saying someone edited the post, but what is the user supposed to do with that information? Juggle a new web browser tab open? Then what? The workflow is clearly wonky.

I like the idea of reusing some of the suggested edit UI here for dealing with conflict.

  • 13
    Please no checkout/locking - it's bad enough that suggested edits lock the post until resolved.
    – Blorgbeard
    Commented May 30, 2011 at 12:13
  • 1
    Yeah, I don't think the checkout would work very well. I'm sure we've all started editing a post and then got distracted by some random YouTube video we just got an email about. It would be difficult to get the right balance for the timeout methinks. I quite like your first idea too.
    – Andy E
    Commented May 30, 2011 at 12:16
  • I'm not sure what the point of the "other editors" list is. What happens if you submit anyway; you wipe out their changes? Commented May 30, 2011 at 17:52
  • I don't see how displaying who is editing concurrently would do anything at all to address this. Commented May 31, 2011 at 3:33
  • 3
    @waffles, one solution to the 'checkout' problem is to have a 'keep-alive' of (say) 20 seconds. If you stop doing anything, you lose the ticket and someone else can pick it up from there. If @AndyE goes off slacking on YouTube, too bad for him :)
    – Benjol
    Commented May 31, 2011 at 6:19

The premise of this question is kind of incorrect.

We poll the server every 45 seconds and you will get notified via topbar when someone else has edited (and saved) while you are editing.

Be advised: this post has been edited {0} time{1} by other users while you were editing.

Now, for very rapid edits, everyone is just screwed; there's no way of getting around that, that I can see. And merging in the case of these sorts of edits is going to be incredibly painful. Most of the edits I see are ...

  • on posts which aren't terribly long (to be fair, our average post length is around 500 characters, meaning it is a minefield of merge conflicts for any line-based merge algorithm.)

  • in the same area of the post (the obvious ones)

  • some much more substantive than others, leading to some obvious candidates for throwing away trivial edits in favor of substantive edits

Actually, now that I have thought this through a bit more, perhaps there is something we can do:

  1. There are some easy opportunities for merging when someone doesn't edit tags/title/body and another user does. Not sure how common it is, but it would be easy and totally safe.

  2. The larger edits should "win" in every case -- if you made a tiny edit, you suck and your edit should always be discarded in favor of the larger, more substantive edit.

Point #2 would immediately favor the non-slackers which I think is the point of your request.

update: #1 was was already implemented a while ago, apologies to Sam for not realizing that. #2 is now implemented. That is, if you want your edit to "win", make it significantly larger than the other edit you are competing with, and it will -- always.

  • Excellent, I think the solution is definitely an improvement. Honestly, I thought the 45 second poll had gone because I'd not seen it for the edit clashes I had yesterday. I guess the submissions were just too close together.
    – Andy E
    Commented May 31, 2011 at 10:42

N.B. The workaround described in this answer is now no longer necessary and would in fact be counterproductive because the edit submission logic has been changed to favor more comprehensive edits. Instead, simply continue with your comprehensive edit and submit it when you are finished.

I like your suggestion. Here is a workaround using the existing workflow.

First, you already know when this situation is likely to happen: a new question desperately in need of an edit has just appeared with tags that ensure that many users with the edit privilege will see it in a short period of time.

In this situation, someone is bound to edit the question to try fix the problems. In fact multiple people may do so at the same time. If you are thorough, the submission of your edit may be last and your efforts will have been wasted.

When you know this situation is likely to occur you can:

  • give up on editing the question, because you can anticipate the outcome
  • beat them at their own game by using a FGITW strategy

Since thorough edits are usually good edits, we don't want to you to give up. Instead, until the workflow is adapted to facilitate your current strategy, you can instead:

  • Fix only the question's most egregious problem in the first edit (e.g. the title)
  • Make additional incremental edits after first edit has been submitted

Since multiple edits close in time are merged, doing this doesn't create a proliferation of edits. It's just like the grace period for answers. Granted is is more work than a single edit, but it can help when multiple people are likely to modify the question at the same time.

A fast fix for the title may dissuade the casual editors and improve your chance of success at giving the question a complete makeover. And even if you are competing with another thorough editor, the potential for wasted effort is lessened by making fewer changes per submission.

  • +1, making incremental edits was one option I was looking at. It makes a little sense, because your edit gets in first and could buy your subsequent edits more time.
    – Andy E
    Commented May 30, 2011 at 17:32
  • 3
    +1: This is a good idea, but it's still pretty easy to run out the 5 minute "incremental edit" clock when fixing up a question which needs grammatical help, or has a big code snippet with tabs -shudder-.
    – jscs
    Commented May 30, 2011 at 17:56
  • 1
    @Josh: Or worse, a big code snippet that has no/randomized indentation. Commented May 31, 2011 at 9:25

You can click "Submit" again to override that message (unless this has changed recently?).

I usually do that and then check the revision log, and rollback if the other user's edit is better, or just edit again and add anything I missed that the other user caught.

  • It did occur to me to try this the first time I got blocked and it didn't work. Unless another user had edited after the first time I tried to submit.
    – Andy E
    Commented May 30, 2011 at 12:19
  • @Andy: So just hitting "Submit" again doesn't work for you? I does for me...
    – sth
    Commented May 30, 2011 at 15:57
  • @sth: it didn't when I tried it. Admittedly I haven't tried it again since then, but will the next time I get edit-blocked.
    – Andy E
    Commented May 30, 2011 at 18:30

You must log in to answer this question.

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