As of now, it is relatively hard to keep-up with pijul development. Keeping a changelop, albeit difficult and cumbersome, can greatly help from this perspective, and it is relatively easy to do when done systematically, after each change.

I foresee a potential drawback to this: to modify the changelog in the same change as the patch itself will introduce potentially unwanted dependencies to said change. So a good call for action may be to do two changes: one that modify pijul, and one that report said modification in the changelog. It would be a good idea to systematically makes the latter depends on the former… but this may require to develop ad-hoc tooling to ease the work of pijul’s contributors.

I like the idea, but I think it would be best to do this after 1.0 releases. I’d imagine there will be many more things to work on after we get most of the usability et al. issues out of the way. Right now, the change history (when said history hasn’t been rebooted…) does a pretty good job of keeping track of development, IMHO.

Whatever happens, it would be nice if we could follow https://keepachangelog.com/en/1.0.0/.

I agree 200%. Things are settling down a bit now, and this looks totally doable. The first two weeks after I announced 1.0.0-alpha have passed way faster than I imagined, and this project moved at a pace I couldn’t even dream of before. This is cool, but it also forced me to work on ten things at the same time for long days.

I foresee a potential drawback to this: to modify the changelog in the same change as the patch itself will introduce potentially unwanted dependencies to said change

We could model that in Pijul, and we almost have the tools: one way to do it is to consider a special diff algorithm and conflict syntax where conflicts are printed without markers and never solved: each new entry in the changelog is a side of the conflict.

We could model that in Pijul, and we almost have the tools: one way to do it is to consider a special diff algorithm and conflict syntax where conflicts are printed without markers and never solved: each new entry in the changelog is a side of the conflict.

That sounds like an overly specialized solution. Just settle on a convention for the format of messages associated with changes that should go to the change log that would make them easily identified. Like having some prefix for the message.

If it is an existing convention such as Conventional Commit, then existing tools for generating change logs from Git commits (e.g. Conventional Changelog could be modified to work with Pijul.

There’s a changelog now! At last.