Review a difference before accepting a merge
Keep the original, make the comparison readable, then accept intentional changes.
Give the two sides a clear meaning
Before comparing, decide which side is the baseline and which contains proposed changes. Reversing the sides reverses the meaning of additions and deletions. Use descriptive filenames in your own workflow and verify the first and last lines after loading. DiffTidy compares text; it cannot know whether a change has been approved or whether a newer timestamp means a better version.
Review a change in its surrounding context
A changed number can be more important than several added paragraphs. In this example a retry limit and a note both change. Inspect each block, read neighboring lines and accept only the intended result. If a merge action replaces a whole block, confirm that unchanged context and adjacent edits remain correct. Keep your original separately so an accidental choice is recoverable even after a reload.
Before: retries=3
Before: note=standard
After: retries=5
After: note=temporaryVerify the exported result
After assembling a result, compare it against the baseline again. Confirm that only intended changes remain, then run the receiving program’s parser or tests if the text is executable configuration or source code. DiffTidy does not execute the content or prove that a merge is valid code. A conflict-free textual result can still contain a logical mistake. Avoid relying on color alone; read the change labels and actual lines.