Help:Edit conflict

This page discusses conflicts, and how to deal with them. To understand what an conflict is, consider the following situation:

Layout of the -conflict page[]

Note: The following explanation may not be consistent with the ing interface that you see, depending on your account's preferences and gadgets, which web browser you use, and whether you use Wikipedia's traditional or, visual or, or a mobile app to .
Your changes have been copied into a box at the very end of the page. The box with your changes is labeled "Your text". On a large page with many changes, you may have to scroll down a very long way to find the box that contains your changes.

At the top of the -conflict page is an ing box containing Bob's version of the whole page, even if Alice is doing section ing.

At the bottom of the -conflict page is a second ing box containing the text Alice was going to submit. This will be Alice's version of the page or section she was ing.

Between the two ing boxes is a diff that shows the difference between Bob's and Alice's version of the article. For the section Alice is ing, it shows Alice's changes and Bob's possible changes, except for sections where Alice and Bob have both made the same change. For the other sections, it shows the full new text as if all that text was added.

Alice can in the upper ing box and press Publish changes. In the case Alice was ing only a section, this will be interpreted as the new version of the section, hence produce duplication of the other sections, unless Alice deletes them before saving. (This seems to be a bug.) The best solution in this case is to save your new text outside of Wikipedia (e.g., to the clipboard), cancel out, then try again.

At certain times when pressing Publish changes and the system is slow, one may be able to make multiple s to the same page before the system responds. This produces an conflict with oneself. In this case the upper text may be the old version instead of the one involving the first , i.e., the system notices the earlier change but has not processed it yet. A moment later, while one is viewing the -conflict page, the first change is carried out in the background, and the upper text no longer is the current one. Hence, the diff shows the combined , and in the case of section ing, like before, the "addition" of the other sections. If you choose to publish your work in this type of conflict, it will result in the removal of your previous ing from the page.

Resolving an conflict[]

In most situations, an conflict can be resolved by merging the two changes to a page — including the contributions of both ors.

If Alice made only small changes, and Bob made large changes, she may choose to work from Bob's version, and re-merge her changes in. Alice might choose to add some text like "via conflict" to the summary, or use template {{ conflict}} on a Discussion/Talk page, to warn Bob and others that she had to do this – Bob can then peer review her merging for accuracy.

If Alice made large changes, and Bob made small changes, Alice may choose to work from her version. One option is for Alice to copy the bottom text into the top text (or just copy over the one section of the top text, if Alice was section ing), with an appropriate summary (e.g., "via conflict, will remerge"). Then Alice can view the page history, determine Bob's changes, and re-apply them to her version, in a separate .

If both Alice and Bob made large changes, matters become complicated, and Alice and Bob just have to do the best they can. For example, if both Alice and Bob simultaneously add a large section of text on the same subject, then it may be best for Alice to submit her changes, and then for Alice and Bob to both have a look at the two versions and decide between themselves which version is better.

Alice should not just post her changes over the top of Bob's. We assume good faith – mistakes are occasionally made, and newcomers may not understand the conflict window. However, Alice must not routinely ignore conflicts. It is absolutely not acceptable for Alice to overwrite Bob out of laziness. We encourage contributors to double-check their merges by using the diff feature.

Logical conflicts[]

(This is a conflict between ors that is undetectable by the mechanism that decides whether to give the " conflict" message.)

Some people by copying the source text into a text or, making lots of changes (reorganising, adding new content, etc.), and then, when they're done, pasting the whole thing back onto Wikipedia as a single (new) . If someone else has made changes in the meantime these changes would get lost in the paste back. People who in this manner should either:

The second method is not foolproof, since another or may save changes in the time interval between the retrieval of the page history and the final pasting back. This can be detected by checking the page history again afterwards.

If third-party software that assists a user to a page in an external or does not follow the first bullet point above (or the equivalent measure, if any, for the method it is using to access Wikipedia) and causes a logical conflict, then that is a software bug which should be reported to the software developers of the third-party software being used.


Sometimes mistakes will be made in the merging process, because Alice is human, and this may cause some of Bob's changes to be accidentally reversed. Logical conflicts aren't always immediately visible. Sometimes Alice may have good reasons for thinking that Bob's improvements aren't useful. In this case, Bob and Alice are expected to resolve their differences amicably.

If Bob made a small change which Alice accidentally replaced, Bob must not revert to his version. It is absolutely not acceptable for Bob to reverse Alice's major improvements to the page out of a desire to protect his minor improvements, or to punish Alice for her carelessness. This is particularly important if the page has subsequently been ed by other ors.

The best approach for Bob in this circumstance is to Alice's version, reinstate his minor improvements, and leave Alice's major improvements intact. He may also add something to the summary to indicate that he had to do this – for example: "Reinstating link which Alice accidentally removed". Alice should then apologize to Bob for her mistake, and thank him for preserving her improvements.

If Alice repeats her error, then the best approach is for Bob to have a friendly word on her talk page, point her to this page, and ask her if she could take a little more care in the future. This is particularly important for newcomers, who may not understand the correct way to resolve conflicts, though even experienced users may need the occasional friendly reminder.


When saving a previous version (i.e., when reverting) or a new version based on that (a modified reversion) the conflict warning and prevention system is not triggered and a possible new made in the meantime is unintentionally reverted also, see Reverting a page to an earlier version. To avoid this problem one can copy the text from the box of the old version into the box of the latest version. In some sense, this can cause hidden conflicts: you may overwrite someone else's changes without realising that you are doing so. It's always wise to check the diff after performing a revert, just as you would after posting via conflict. Preferably, one can simply try to avoid reversion wars.


Did someone tell you that section ing prevents conflicts? That was true in very old versions of MediaWiki software, but it hasn't been the case since about 2006.

Edit conflicts are irritating and can be time-consuming, but there are ways to make them less frequent or easier to recover from.

Saving your work frequently reduces the risk of your experiencing an conflict, and when you do they should be easier to resolve.

When practical, one area of the article at a time. This reduces conflicts because the system can cope if different ors are ing different areas at the same time. Both the source code or and the visual or use CVS-style -conflict merging, based on the diff3 utility. This feature triggers an conflict only if users attempt to the same few lines. Edit conflict detection is by line/paragraph.

Start new articles in sandboxes and move them to mainspace only when you are ready to stop ing them for an hour or so and instead watch what others do to them.

Wikipedia has an "In Use" notice in its Template namespace that people may use when ing a page over a long period of time. This may discourage other ors from ing while you are ing. Simply put {{inuse}} on an article before proceeding with a major , and remove the template when the ing is complete.

See also[]