Talk:Unified diff

Latest revision as of 00:00, 21 September 2025

[edit] Identification mess

Not always does unified diff or patch files consistently begins with @@. Some, notably older unified diff files also contains *** and --- instead of --- and +++ to provide file changes, e.g.

 *** lib/cap/atalkdbm.c.orig	Wed Mar 20 17:02:57 1991
 --- lib/cap/atalkdbm.c	Wed Mar 20 17:03:30 1991
 ***************
 *** 1,7 ****
   /*
 !  * $Date: 91/03/15 14:56:00 $
 !  * $Header: atalkdbm.c,v 2.3 91/03/15 14:56:00 djh Exp $
 !  * $Revision: 2.3 $

Source: https://tsubaki.st.ryukoku.ac.jp/pub/network/cap/cap.patches/cap60.patch001

In general, a modern patch utility will often detect whether or not if the supplied file is in the specified unified diff format and prompt if necessary.

Anonymoususer852 (talk) 00:00, 21 September 2025 (UTC)

[edit] Interesting quirks when applying changes via the utilities

[edit] .orig/.rej files

patch will produce a file with .orig extension if:

• --backup or --backup-if-mismatch is set, or
• the targeted file is successfully applied with fuzzing
  • fuzzing "only applies to diffs that have context, and causes patch to ignore up to that many lines of context in looking for places to install a hunk." -- https://www.gnu.org/software/diffutils/manual/html_node/Inexact.html

In addition, patch will produce a file with .rej extension if:

• the specified diff/patch file does not correctly match with the contents of the file to be patched itself, or
• the fuzz factor was set too low

git apply --3way ... in particular will not generate either of these files in applicable cases, if the changes did not apply cleanly.

[edit] Preserving timestamp

When applying changes via GNU patch, the updated file or files often has the last-modified time adjusted to the date when the changes were applied. This is a rather unfortunate side-effect in which those wanting to preserve timestamp that is as indicated (which is an optional field) in the supplied unified diff or patch be consequently lost in the process. While it is possible to re-adjust the last-modified timestamp to more accurately represent the time when it was initially modified, via touch, there is no trivial way of doing that as either,

• Indicated timestamp format is tied to the creator of unified diff's locale,
  • i.e. it may or may not be in ISO 8601 format,
  • timezone is specific to the creator of unified diff, which can cause time skew/variance
• The optional field is not in a time format, but RCS/VCS indicating changes from the version that it was previously from, or,
• The optional field is empty

Anonymoususer852 (talk) 00:00, 21 September 2025 (UTC)