Developer tools · Text comparison
Why a Diff Shows a Moved Paragraph as Deleted and Added Again
· How it works
text-diff code-review developer-workflow
Explains why line-based comparison has no concept of movement, how a relocated block appears in the output, and practical ways to review reorganised documents anyway.
You moved one section and the diff turned red and green — describes the surprise of a large diff after a small reorganisation
Moving a section can create a large red block near its old position and an equally large green block near its new one. The words may be untouched. What changed is their order relative to surrounding lines, and order is part of the sequence that a line diff compares.
This output is easier to trust once you stop expecting a “move” operation. ToolAcre emits equal, remove and add rows only. A reviewer can recognize matching blocks at two locations, but the program does not join them with an arrow or assert that one was copied from the other.
Line diffs only know kept, removed and inserted — explains that the algorithm looks for lines common to both versions in the same order, so order changes break the match
LCS keeps lines that occur in both versions in the same relative order. If section Beta precedes Gamma on the left but follows Gamma on the right, one of those blocks cannot remain in the chosen common subsequence. It must leave and re-enter the edit story.
A changed line is represented with the same primitive vocabulary: remove the old row and add the new row. This simplicity keeps line numbers and counts exact. It also means visual similarity between distant removed and added blocks is an observation for the reviewer, not a typed result from the algorithm.
Why keeping order is the whole point — shows that allowing out-of-order matches would make the result ambiguous and far slower to compute
Ordered matching is the definition used by this implementation. Permitting arbitrary out-of-order pairing would answer a different question and require rules for duplicates, partial edits and competing destinations. The repository does not benchmark such an alternative, so this article makes no unsupported performance comparison.
The practical benefit of order is an unambiguous reading around stable neighbors. Equal prefix and suffix rows anchor the changed middle, and each emitted row advances a known side. Even when ties exist, the reconstruction remains a coherent path through both documents rather than a bag of similar lines.
Preserving order defines LCS matching; this source does not prove a universal speed penalty for moves
Take a README with Intro, Install, Configure and License sections, then place Configure before Install. Lines inside one block will appear removed at the original location and added near the destination while whichever ordering the LCS retains stays unchanged.
Add one wording edit inside the moved block and the pair is no longer visually identical. Compare the block texts directly rather than assuming every green line is merely relocation. Original one-based line numbers help you locate both copies and confirm whether content changed during the move.
Reviewing moves in practice — suggests comparing in two passes: first with the sections restored to their original order to catch edits, then confirming the move separately
For a careful review, first restore the original section order in a temporary copy and compare wording. That pass isolates edits inside the block. Then compare the true reordered version to confirm placement. Two narrow questions are easier to answer than one screen combining relocation and revision.
Do not approve by matching only the first and last lines of a long block. Repeated headings, blank rows or duplicated examples can create misleading visual pairs. Check the complete removed and added ranges, including punctuation, case and any whitespace that the active options may normalize.
How some version-control tools approximate move detection — describes colour-coded moved-line heuristics in git as a post-processing step, not part of the diff itself
Some review products may add moved-line presentation after their basic diff, but ToolAcre contains no such pass. Its source has no similarity threshold, block fingerprint or moved-row type. Naming another product’s heuristic without its source would blur a useful boundary in this tool.
Here the defensible technique is manual pairing. Collapse long unchanged runs to bring the changed regions closer, then inspect repeated text. The collapse function only replaces long equal runs with skip markers; it does not alter the underlying result or infer a relationship between changes.
Move-detection behavior in other tools is outside this repository’s evidence
Text diff does not merge versions, preserve authorship, infer intent or recognize a rename. It cannot tell whether a duplicate block was moved, copied or independently recreated. Those conclusions need history or domain evidence that two pasted states do not carry.
It also does not parse Markdown structure. A heading marker is just part of a line. Use a repository review when commit history matters, and use this browser view as a focused second opinion on two concrete states rather than as a replacement for provenance.
Takeaway: read a move as a pair — summarises how to spot the matched pair of blocks and use the browser-based tool for a quick second pass without uploading the document
When a reorder fills the screen, look for a removed range and an added range with the same original text. Treat them as a candidate pair, then search within the pair for real edits. This reading method respects what the line algorithm proves and what only a human can infer.
Because comparison and rendering stay in the loaded tool modules, a draft can be inspected without a text-processing request. Paste only the material appropriate for your browser environment, compare, and clear the editors when finished; the tool itself exposes no saved-comparison history.