I spent a couple hours yesterday putting together a plain HTML site for viewing a pijul repo, using eleventy (11ty.dev, a static site generator). The code is a mess and there are a ton of bugs, but it does show you a list of files and also the output of pijul log. I was surprised by how easily it started to come together once I got started. I’ll keep working on it. Here’s my very rough draft so far:
https://lovely-tangible-double.glitch.me/ (hosted on glitch temporarily).
One of the many things I like about pijul is how easy it is to save a change as a plain text file and then pipe that into pijul apply later. So the log page (https://lovely-tangible-double.glitch.me/log/0.html) lets you copy a command for each change that will curl the change text and then pipe that into pijul apply.
Right now it calls pijul change on every change in the repo in order to generate those text files – I’ll add caching at some point. pijul change is shockingly fast, though. It still only took about one minute to generate the site for the pijul repo itself, which produced 1325 files.
Does anyone have any ideas for features I should implement? What would you like to have if you were displaying a pijul repo on your personal site?
1 Like
The thing that is missing (even from Nest) is context, showing the patch in amongst the other lines of the file.
People like GitHub interface and other forges, so making that sort of interface for Pijul makes sense.
If you take a look at the script I wrote for dependencies (it was before I asked for the dependents command), you’ll see that it generates HTML with targets and anchors to jump between dependencies.
The thing that is missing (even from Nest) is context, showing the patch in amongst the other lines of the file.
I’m thinking about how to do that and I think it might be a little tricky. I could take the change and try overlaying it onto the file that is currently in the working copy, but when looking at older changes, the change might not fit the file in its current state.
So in order to get what the file looked like at the time the change was made, that would mean taking a snapshot of every file for every change. Which would end up being a ton of files to generate.
Also, because pijul allows for flexibility in applying only some changes to your local repo, that could mean that the file being displayed does not actually match what that file looks like for other users. I’m hesitant to copy UI conventions from other forges and lose some of what makes pijul unique in the process, like the fact that there isn’t really a specific “state” for a file for a given change.
Do you think it would be enough to simply have links to the files that are affected by a change? Like, just a link to the current, pristine version of the file. Which could mean that the contents of that change are no longer in the file at all, depending on how old the change is.
The issues you bring up are the very reasons that I think Pijul needs more refinement. It might be that patches make it “easier” to add and subtract from the file, but the overall goal is version control, not applying patches.
Collaborative work, especially code, needs to have a reliable way to retrieve each state, meaning that the log should be the same for everyone, and each person has certainty that their repo is a match to the colleague’s or the stable release or the latest submitted fix that they are supposed to test.
The current state of Pijul is that it works for a single author who only adds (occasionally subtracting or rearranging the latest). If you try to use it in a bigger group, with QA and testing and CI, it falls apart.
It is fixable. If you can, read about Darcs, and how you can choose to reorder the patches (it seems to me that date should be the default ordering), and how tags create a state that stops the dependency search.
As for context lines, see Nest discussion 833: missing command to show a file at a certain state and the related request 872: Any plan to support unified diff ouput ?