Incorporating discussions into the repo itself


So, I’ve been thinking about this since seeing it in fossil. Why don’t we integrate discussions into the repo itself? After all, they are just as important to the history of a project as the commit log itself.

This brings:

  1. decoupling from the host (the nest);
  2. a lonely developer working on a local only project can still manage his own issues (then if he ever decides to host it on the nest they will be automatically integrated).

For the implementation, we could either choose:

  1. an unversioned database in the .pijul directory
  2. a versioned database in a hidden __discussions branch

The database would be something like this:

       {'title': 'Issue title',
         'content': [
             {'date': date, 'author': author, 'message': 'the content', 'reactions': 'reactions from users, like :ok_hand:, :heart: ' }   
             {'date': date, 'author': author, 'message': 'the content', 'reactions': 'reactions from users, like :ok_hand:, :heart: ' }   


I wanted to do that initially when I started the Nest: having Nest-compatible decentralised issues would be even better.
At the moment, this suffers from two problems:

  • it is quite opinionated to be hard-coded in Pijul at the moment, since no big project uses Pijul.

  • Having something decentralised requires a fixed format that would last almost forever. At the moment, Nest discussions can still improve a lot. When they’re ready, we can freeze a format and do this.

Meanwhile, why not use a distributed bug tracker such as “bugs everywhere”, and use Pijul as a backend?


external bug trackers are definitely interesting, but as you pointed out they would need nest-compatibility to allow an eventual migration into the nest.

I’m not sure why we need a “fixed format that would last almost forever” for bugs. The internals would be completely behind the scene and managed by pijul itself. A change in the format would mean a bump in pijul version and an automated upgrade of the database, but wouldn’t be anything disruptive like the change in the patch format was.


Having something decentralised requires a fixed format that would last almost forever.

it doesn’t. The formats need to be designed with extendability in mind.


Shameless plug: I’ve recently developed a decentralized issue tracker that works equator well in different SCMs: be it git, metcurial or pijul (or even without one) because it’s based on simpler primitives. It’s part of the SIT project (


Wiki and Issue trackers absolutely should be version controlled and ideally live near the code if for no other reason than software archaeology.

That said, separation of concerns should mean how the wiki and issue tracker work should ideally be independent of the source code management system as much as possible. gh-pages branch seems to work well as a standard for wikis. Just need something human readable for issues (will org-mode take over the world?).