[chipx86]

The repository metadata absolutely should own the commit information.

Diff files are there to represent a delta state of the repository, a difference between a range of changes. Those may be one or more commits, or one more changes across individual files (not all SCMs manage state in terms of atomic commits). File changes, file attribute changes, SCM-specific metadata changes, and commit history information.

That delta state should be able to be applied to another tree in order to get the same end result. This is what diff files are ultimately there for.

Git diffs do this today, and they do it well (but they're pretty Git-specific). Many SCMs (and there are a lot of them) don't include a format on that level, or a format at all. Hence DiffX.

[eqvinox]

I think there's a confusion here between diffs and patches. I would call the thing you're describing a patch, not a diff, and then everything makes much more sense.

(This is not helped by the fact that diffs often come with a .patch file extension… or that the "patch" tool processes diffs…)

Or anyway the nomenclature really sucks in this field. I guess I have no clue whether I have a minority view here.

[chipx86]

Yeah the nomenclature sucks.

When talking about the file, the two terms are often used interchangeably (and are usually a .diff or a .patch extension).

For fun, the GNU Patch manpage says:

"NAME: patch - apply a diff file to an original"

followed by:

"patch takes a patch file patchfile containing ..."

"patch tries to skip any leading garbage, apply the diff, and then ..."