#94 `pijul unrec` should be able to hard-unrecord

Closed on November 30, 2020
cole-h on November 17, 2020

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].

loewenheim on November 19, 2020

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

cole-h on November 19, 2020

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).

pmeunier on November 19, 2020

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?

cole-h on November 19, 2020

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).

loewenheim on November 21, 2020

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

pmeunier added a change on November 30, 2020
5DVRL6MFXQOCPOZMYSKBERMRRVUTYRL2SRGRTU2MH4IEOFCDKM3QC
main
pmeunier on November 30, 2020

Done! Thanks for this suggestion.

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

pmeunier closed this discussion on November 30, 2020