The sound distributed version control system

#107 Email-friendly change format

Opened by cole-h on November 22, 2020
cole-h on November 22, 2020

While I do like the patch format, I think it has some things (really one that I can think of at this time) that wouldn’t be very conducive for email-exchanged patches (e.g. the workflow that would be used on a prospective

My main concern is really the fact that there is no place to put “commentary” (as it’s commonly referred to when using git) – stuff that isn’t suitable for the change’s description, but e.g. to communicate what has changed since the last version. For those unfamiliar (I’d imagine that’s not many, but just to be safe), you can put such commentary below a marker line, ---, after which the diff’s contents follow.

An idea to resolve this (or, at the very least, resolve my above concern) would be for the ability to have commentary precede the patch’s contents. Something like the following:

Here is some timely commentary. In this version of the patch, I changed foo to
bar and created a wrapper type, Qux, around Baz to shorten typing in all
the places it is used. PTAL.


message = 'Introduce Qux as a wrapper type'
timestamp = '2020-11-23T03:19:46.908209786Z'

# No `name =` since that is really only relevant for the Nest. As such, it
# really should be optional... In this example, we assume it is.
full_name = 'Cole Helbling'
email = 'cole@***.com'

# Dependencies

# Changes
# ....

For this to work as expected, it should be possible to pijul apply < file.pijul, with the above contents, and pijul should know to ignore everything before the ---.

loewenheim on November 24, 2020

Am I understanding this correctly that the difference between “commentary” and the description of a patch is that the latter is something that pijul cares about, whereas the former just gets ignored outright?