Jan Engelhardt <jengelh@xxxxxxxxxx> writes:
> Any insights?
We have "index ..." and other metainformation (most noticeable when
renames and mode changes are involved) before any hunk begins. POSIX
unified context format of course would not know about them either.
In the context of git, file modification time often does not have a
defined meaning. If you are comparing two arbitrary tree objects (or two
arbitrary blob objects), there is no concept of "timestamp of the preimage
and the postimage". If you are comparing two commits, you _could_ show
the timestamps of the commits, but that is misleading and useless
information. The paths being shown may not have been changed by the newer
commit being compared, but by some other commit in-between the two commits
(and even that is not guaranteed --- the two commits may not have any
ancestry relationship, and/or the clock of the committer who made one of
these commits may have had skews).
The enhancements and ommissions were chosen not to confuse tools that
people use to process patches. The metainformation headers are safely
ignored by "patch", for example (of course "patch" does not know about
renames yet, but that can be fixed later). Even though "patch" _can_
optionally set the timestamp of the affected files, nobody sane would do
so in the context of source code control (it will screw up "make").
The answer to your question depends on how anal you would want to be, but
no, we fundamentally cannot produce "unidiff -- _really_" in the "POSIX
unified context format" without losing useful information (renames and
modes) nor without adding information that is meaningless (timestamps).
But on the other hand, you can say what we produce is in unified context
format to the same extent that RCS and CVS produces unified when given -u
option (i.e. "rcsdiff -u", "cvs diff -u").
For example, "rcsdiff -u" shows something like:
diff -u -r1.1 -r1.2
--- Make 1995/01/08 20:50:24 1.1
+++ Make 2001/10/04 07:14:29 1.2
@@ -1,7 +1,11 @@
#!/bin/sh
-...
It has cruft after the timestamp, and the timestamp itself is not even in
the format POSIX expects to see (see
http://www.opengroup.org/onlinepubs/9699919799/utilities/diff.html#tag_20_34_10_07
if you really care).
Is it in violation of POSIX unified context format? Of course yes. Is it
then not in unified context format at all?
For all practical purposes, if you (either you human or your tool) know
how to read unified context format, you can process what we (or RCS)
produce.
I used RCS as an example because it has been maintained by the same person
who maintains "GNU diff" and was one of the main player who pushed
"unified context" format to the updated POSIX.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html