Essentially, I’m imagining a pijul unrec --hard (--drop, maybe?) flag that would drop the change as well as its contents, rather than keeping the changes applied (but unrecorded).

Imagine you have some already-recorded and -unrecorded changes. You want to remove one of your recorded changes permanently (e.g. it was a mistake, for debugging, etc.), so you pijul unrec [hash]. Now that change is basically “popped” into the current repository state and might be tough to distinguish between the “good” unrecoded changes and the now “bad” ones. This could have been avoided by just pijul unrec --hard [hash].

I agree that this would be nice to have. What do you think of pijul unrec --reset as the flag?

I like it. It best represents the functionality I’d expect, in that pijul unrec --reset should function the same as pijul unrec && pijul reset – but ONLY on the changes from that patch (e.g. any other unrecorded changes should remain untouched).

I agree this would be super useful in many cases, but we can’t really do that, as the remaining changes might depend on the changes introduced by the change you want to unrecord.

For example, if you recorded the addition of a file, and are working in the file, you can’t reset just the file addition. Maybe in this case we could simply return an error, what do yous think?

Definitely agree it should be an error if that happens. Preferably also listing the conflicting file(s) (something I’d also like to see for pijul reset --channel when there are unrecorded changes).

--discard might be another good name for the flag.

Done! Thanks for this suggestion.

This change conflicts from the changes in #104, that’s intended, I’ll resolve the conflicts before pushing.