I think if we could associate a set of key/value string pairs with each change it would increase the number of workflows we could use in Pijul without high error rates (such as applying changes to channels where we don’t want them, etc).

There are various ways these could be used

• Tracking which changes have been present in a UAT tested state
• Tracking which release of a project first contained each change
• Where two different projects share a common origin: tracking which changes are meant to be shared between them.

This is already possible in libpijul, only not implemented in the command-line tool, how would you want to edit that? This would probably be a good first contribution btw, because it only touches pijul (the CLI), not libpijul.

Incidentally, all three workflows you propose are already possible without extra metadata, either with tags (which aren’t patches) or with states (pijul log --state).