IP4CUEBEHNVTHTLRBXH27TDN6H5GA34GMR6LWY2GGHWGF6LW24CQC
While testing, I found the following oddities/bugs with the current implementation of pijul reset
:
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
Repeat the example above but now issue pijul reset bar
and nothing gets reset.
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
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 ofpijul 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.