The documentation also lists unrecord --reset as the opposite of applying, but I think this has the potential to be a bit confusing as the way to remove a change form the working set.
record introduces a brand new change into the system. It’s something from the working directory that hasn’t been seen before. So unrecord to me implies that the change may be deleted permanently, or at least the action is somewhat more destructive. I see it still in the .pijul/changes directory, but trying to apply it to the channel again results in an error:
Outputting repository ←
Error: Cannot dropped a borrowed channel: "FhlNqMSXabk7BnQxJ4ng"
Meanwhile apply takes a change that is in the repository and simply, well, applies that over the current channel, and outputs to the working directory. I think having a simple opposite of this would be a neater way to go. I.e. pijul unapply <Change ID> will keep the change, so it can be applied again, but. I think Pijul can probably attempt to apply the reverse patch even if the working file has unrecorded changes, but if not or if a conflict ensues then it should produce an error message and refuse to overwrite the file, lest any unrecorded work be destroyed. unrecord then may be a more suitable way to delete changes from the repository permanently. In my case, I simply want to see what the file looks like with a change removed, and then be able to apply it again easily.
I think the symmetry would be easier for new users, and also, the need for the --reset makes it easy to forget the flag, unrecord the change but now not be able to unapply it.
Interested in what others think. From my own experience, one way bazaar is easier than git is that many actions have simple opposites. Git is very hard to learn, because the way the commands are conflated and do many things at the same time. I like commit-uncommit pairings.
Alternative options could include a pijul undo command that in general would then perform the opposite of pasting the arguments previously given (when this is possible), or keeping more of a history stack of operations, so that it were always possible to go back and get to a previous known state. But this is more long-term than renaming a command obviously.
The documentation also lists
unrecord --resetas the opposite of applying, but I think this has the potential to be a bit confusing as the way to remove a change form the working set.recordintroduces a brand new change into the system. It’s something from the working directory that hasn’t been seen before. Sounrecordto me implies that the change may be deleted permanently, or at least the action is somewhat more destructive. I see it still in the.pijul/changesdirectory, but trying to apply it to the channel again results in an error:Meanwhile
applytakes a change that is in the repository and simply, well, applies that over the current channel, and outputs to the working directory. I think having a simple opposite of this would be a neater way to go. I.e.pijul unapply <Change ID>will keep the change, so it can be applied again, but. I think Pijul can probably attempt to apply the reverse patch even if the working file has unrecorded changes, but if not or if a conflict ensues then it should produce an error message and refuse to overwrite the file, lest any unrecorded work be destroyed.unrecordthen may be a more suitable way to delete changes from the repository permanently. In my case, I simply want to see what the file looks like with a change removed, and then be able to apply it again easily.I think the symmetry would be easier for new users, and also, the need for the
--resetmakes it easy to forget the flag, unrecord the change but now not be able to unapply it.Interested in what others think. From my own experience, one way bazaar is easier than git is that many actions have simple opposites. Git is very hard to learn, because the way the commands are conflated and do many things at the same time. I like
commit-uncommitpairings.Alternative options could include a
pijul undocommand that in general would then perform the opposite of pasting the arguments previously given (when this is possible), or keeping more of a history stack of operations, so that it were always possible to go back and get to a previous known state. But this is more long-term than renaming a command obviously.