I just installed pijul 2 days ago and tried to test things out.
I am using 1.0.0-beta.21
I read somewhere that in pijul there is no git checkout "old-commit", to achieve something like that I have to fork the channel, then unrecord the changes to go back to old state.
When I am testing it I found the behaviour of pijul is strange and confusing. I think it is a bug.
The strange behaviour is that, when I record a change, fork the channel, switch to new channel, unrecord the latest change, then run pijul diff, it shows nothing. Run pijul status, it shows the working copy is clean, but it is not.
After that, I modify the file, then run pijul status or pijul diff again, it show the unrecord change with the newly modified change. The unrecord change should be shown in the first pijul diff or pijul stauts before I modify the file again.
To reproduce:
$ pijul init
Repository created at /tmp/pijul
$ pijul add .ignore
Tracked 1 path(s)
$ pijul record -am 'init'
Hash: QZVD3TAPV57LULTSKX7EH7QNV3CXRI2OH4LVLX2MB5LS2N7FMK4AC
$ echo "First line" >> test.txt
$ pijul add test.txt
Tracked 1 path(s)
$ pijul record -am 'test.txt: add "First line"'
Hash: 6T2RWZXD7WL2HDP4KYSWOSW34OHWA5DH6CO7CHES3S3WVMBKYKBQC
$ echo "Second line" >> test.txt
$ pijul record -am 'test.txt: add "Second line"'
Hash: VI5OKUT3PO7YCR5SDNLXPAYDXNJAWAKR3QX6NAXNXG2YRBGWE4BQC
$ pijul fork rewind
$ pijul channel switch rewind
Outputting repository… done Reset given paths to last recorded change
$ pijul unrecord VI5OKUT3PO7YCR5SDNLXPAYDXNJAWAKR3QX6NAXNXG2YRBGWE4BQC
$ pijul diff # <========== Bug here
$ pijul status # <========== Bug here
On channel: rewind
Nothing to record, working copy is clean.
$ echo "Third line" >> test.txt
$ pijul diff
message = ""
timestamp = "2026-08-19T10:52:49.178901168Z"
authors = []
# Dependencies
[2] 6T2RWZXD7WL2HDP4KYSWOSW34OHWA5DH6CO7CHES3S3WVMBKYKBQC # test.txt: add "First line"
# Hunks
1. Edit in "test.txt":2 2.1 "UTF-8"
up 2.13, new 1:24, down
+ Second line
+ Third line
$ pijul status
On channel: rewind
Changes not recorded:
(use "pijul record [file]..." to record into a change)
(use "pijul reset [file]..." to discard changes)
modified test.txt
This strange behaviour only happen when I fork the channel.
If I just run pijul unrecord in the main channel then run pijul diff or pijul status, it can show the unrecord change as expected.
Just test again. Sometimes it cannot trigger the bug
The following script can trigger it 100% in my case.
Please run the below script in empty directory.
#!/usr/bin/env bash
pijul init
pijul add .ignore "$0"
pijul record -am 'init'
echo "First line" >>test.txt
pijul add test.txt
pijul record -am 'test.txt: add "First line"'
echo "Second line" >>test.txt
pijul record -am 'test.txt: add "Second line"'
pijul fork rewind
sleep 1 # This is necessary to trigger it with unknown reason
pijul channel switch rewind
pijul unrecord "$(pijul log --hash-only | head -1)"
echo "==================Running pijul diff 1st time=================="
pijul diff # Should show "Second line", but output nothing
echo "==================Running pijul status 1st time================"
pijul status # Should show "modified test.txt", but output "Nothing to record, working copy is clean."
echo "Third line" >>test.txt
echo "==================Running pijul diff 2nd time=================="
pijul diff # 2nd run show "Second line" and "Third line"
echo "==================Running pijul status 2nd time================"
pijul status # 2nd run show "modified test.txt"
My stdout running it in /tmp/pijul:
Repository created at /tmp/pijul
Tracked 2 path(s)
Hash: JYBPC2HKVPF6FSQ3HTVWEPVNPNVPCYBEQBZPS2AA335ZJBBE5HBAC
Tracked 1 path(s)
Hash: NAN5H5UXWBY6BF32DR6FJARRMKRDEMKJQVGSCUUHBUTOO6LIB56QC
Hash: KSHDDH2GFJ6FNOVY3YDNOAFK7AASE7D3UY7ECCXB746WXWZK2QNQC
Outputting repository… done Reset given paths to last recorded change
==================Running pijul diff 1st time==================
==================Running pijul status 1st time================
On channel: rewind
Nothing to record, working copy is clean.
==================Running pijul diff 2nd time==================
message = ""
timestamp = "2026-08-20T15:39:16.548336515Z"
authors = []
# Dependencies
[2] NAN5H5UXWBY6BF32DR6FJARRMKRDEMKJQVGSCUUHBUTOO6LIB56QC # test.txt: add "First line"
# Hunks
1. Edit in "test.txt":2 2.1 "UTF-8"
up 2.13, new 1:24, down
+ Second line
+ Third line
==================Running pijul status 2nd time================
On channel: rewind
Changes not recorded:
(use "pijul record [file]..." to record into a change)
(use "pijul reset [file]..." to discard changes)
modified test.txt
Confirmed this is first introduced in beta.15 after a little test.
Could be a bug of unrecord wrt working copy. In some cases unrecord fails to update the mtime or its internal representation of the mtime. Is this still the case with the version I published today (pijul-core beta.22)? Also confirm by touching the files if you want.
1 Like
Thanks for your reply!
I am not sure if it is the correct way to get (pijul-core beta.22). The way I do it is I downloaded pijul-1.0.0-beta.21 with
curl -Lo pijul-1.0.0-beta.21.tar.gz "https://static.crates.io/crates/pijul/1.0.0-beta.21/download"
, and then modified the Cargo.toml dependencies.pijul-core version from 1.0.0-beta.20 to 1.0.0-beta.22, then run cargo build.
For pijul-1.0.0-beta.21 without modifying the Cargo.toml, touching the files after pijul channel switch and pijul unrecord and before pijul status and pijul diff show the correct result.
However for pijul-1.0.0-beta.21 with changing dependencies.pijul-core version to 1.0.0-beta.22 in Cargo.toml, both touching and not touching the file like above shows the same incorrect result: first pijul diff is empty and second pijul diff not showing the "Second line" modified entry, only show "Third line".
No need to do that, I think just cargo install pijul --version "^1.0.0-beta.21" would pick up the latest pijul-core. If not, let me know, I’ll publish a new Pijul.
It cannot pick up the latest pijul-core.
Ok, confirmed on the latest version, definitely a bug in unrecord (including the reason for sleep 1). Let me fix that.
Alright, fixed in pijul 1.0.0-beta.22.
1 Like
Yes it is fixed with cargo install pijul --version "^1.0.0-beta.22". Thank you so much!