The sound distributed version control system

#248 pijul unrecord --reset does not perform reset when there are no pending changes

Closed on January 7, 2021
GarettWithOneR on January 6, 2021

I’ve tried this commands with two different repositories now and haven’t been able to produce the behaviour described in the documentation. I can’t find any difference between the results of the of the pijul unrecord command and the pijul unrecord --reset command. The changes that were unrecorded still appear in the working copy either way. I’ve tried looking into the issue myself but can’t quite nail it down, so I was hoping someone more familiar with the code base could take a look.

            if let Some(h) = pending_hash {
                txn.output_repository_no_pending(
                    &mut repo.working_copy,
                    &repo.changes,
                    &mut channel,
                    "",
                    true,
                )?;
                txn.unrecord(&repo.changes, &mut channel, &h)?;
                if cfg!(feature = "keep-changes") {
                    repo.changes.del_change(&h)?;
                }
            }

I think the call to output_repository_no_pending is supposed to be the reset, but I can’t figure out why it isn’t working.

pmeunier on January 7, 2021

I just tested this now, and it did what I expected it to do. pijul unrecord --reset doesn’t reset your repository, it just reverts the changes that were in the change you’re unrecording.

If you start from a repository with no “pending” changes (for example just after pijul reset), pijul unrecord --reset $H is equivalent to pijul unrecord $H; pijul reset. However, if you start with pending changes, pijul unrecord --reset $H will only revert the actions of change $H from your working copy, while leaving the rest of the pending changes untouched.

pmeunier on January 7, 2021

Also, pijul unrecord $H doesn’t touch the working copy, it just removes a patch from history. In other words, pijul unrecord followed by pijul record doesn’t do much (the timestamp of the patches unrecorded and recorded are the only thing that changes, but you can set that with pijul record --timestamp). Similarly, pijul record followed by pijul unrecord does absolutely nothing: you end up in the exact same state as you started.

GarettWithOneR on January 7, 2021

Sorry, I should have been clearer. I just ran pijul unrecord --reset in a repository with no pending changes and it did unrecord the change, but did not touch the working copy. Here are the commands I ran for reference:

gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
R  test5.txt
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul record test5.txt -a -m "Unrecord this"
Hash: 3AMN7FESOIR2UPZNRY35S74XC7GYNOSGWIGCRXS6UZY2WTXV5UHQC
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul unrecord 3AMN7FESOIR2UPZNRY35S74XC7GYNOSGWIGCRXS6UZY2WTXV5UHQC --reset
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
R  test5.txt

I tested it when there were pending changes in the working copy and it did run as expected:

gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
M  test5.txt
M  test6.txt
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul record test5.txt -a -m "Unrecord this"
Hash: 2MRJM3Z7SXRVAS4T74JPSTQEF3UVRPD7HT5FHEDAD5YZCSQBNZVAC
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
M  test6.txt
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul unrecord 2MRJM3Z7SXRVAS4T74JPSTQEF3UVRPD7HT5FHEDAD5YZCSQBNZVAC --reset
gcooper@Garett-PC:~/repos/pijul-vscode-test$ pijul diff --short
M  test6.txt

It seems like the current implementation relies on being able to create a temporary change so when the working copy matches the pristine, it doesn’t perform the reset.

pmeunier added a change on January 7, 2021
MHQBEHJDJ7MUW46HIS24AZFBC4DZDKZNBVBOBOBPML6GGFIS4LQAC
main
pmeunier on January 7, 2021

Thanks, this is fixed now (I just tested).

pmeunier closed this discussion on January 7, 2021
GarettWithOneR on January 7, 2021

Great thanks!