Following the discussion on zulip, I concur that pijul reset should be made safer, because it is a command that destroys genuine knowledge.

Similar to git reset, I changed the implementation of pijul reset to require the --force flag to operate on unrecorded changes.

In a repository with unrecorded changes in the file foo there exist the following cases:

• pijul reset :: Returns an error because of unrecorded changes an suggests using --force
• pijul reset foo :: Resets the file, as this is the intention of the command.
• pijul reset --channel other :: Returns an error because of unrecorded changes. This behaviour already existed.

While testing, I found the following oddities/bugs with the current implementation of pijul reset:

1. The following example resets foo and bar although only foo should be reset:

mkdir -p reset-1
cd reset-1
pijul init
echo foo >foo
echo bar >bar
pijul add foo; pijul record foo -m foo
echo bar >>foo
pijul add bar
# Two changes at this point: Editing of file foo. Addition of file bar.
pijul diff
pijul reset foo
# Now, both changes are gone.
pijul diff

2. Repeat the example above but now issue pijul reset bar and nothing gets reset.

3. The following example correctly detects the pending change but also does not reset bar:

mkdir -p reset-2
cd reset-2
pijul init
echo foo >foo
echo bar >bar
pijul add foo; pijul record foo -m foo
pijul fork otherchan
pijul add bar
# This fails (as it should) because the addition is waiting.
pijul reset --channel otherchan
# This returns normal but does not reset the addition of bar.
pijul reset --channel otherchan --force

A year and a half later, I’ve finally found the time to apply this patch. Sorry for the very long wait.

The behaviour you describe is intended: you can’t reset bar, since it has never been recorded. Also, because it is in the repo we can’t give an error either.