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.
5DVRL6MFXQOCPOZMYSKBERMRRVUTYRL2SRGRTU2MH4IEOFCDKM3QC
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 justpijul unrec --hard [hash]
.