I just accidentally unrecorded a bunch of patches. Like some other users have noticed already, it’s somewhat unintuitive that unrecord --show-changes unrecords all patches remaining in the file and not the other way around. That’s how Git rebase --interactive works, and that’s what most users will expect.

But Git also makes it really easy to bring back commits. I have noticed that I could re-apply unrecorded patches, meaning that they aren’t physically gone (yet). They are just hidden from log (right?). Wouldn’t it then be possible to implement something like Git reflog? As for now, unrecord is a really, really unsafe operation, and I think I will refrain from using it (for now). Or did I miss something?

First of all, I think that (un-)recording of changes should be a much more conscious act; more like removing a file or so. I don’t think that git reflog is meant as a tool for a hot rod working style. To put stuff on the side is what git stash was invented for. But I acknowledge that it’s not the way you came from.

I found the help on unrecord very clear about what the command is supposed to be used for and how it operates. By calling unrecord you already expressed your intent to remove stuff. Obviously, the list of choices you are presented with revolves around removing stuff not retaining it. This is also consistent with the interactive operation of darcs, which is a closer sibling regarding the interface of the tools than git.

Stashing in pijul could work as follows, where <stash> is the name of your “stash channel”:

pijul fork <stash>
# or, if <stash> already exists, then
pijul push -a --to-channel stash .
pijul unrecord --reset ...

Notes

This channel will become garbagy when you feed it from different live channels, but this does no harm. It will be in a state of conflict (would you ever try to check it out), but it is not meant to be checked out. It just serves as a ledger of changes that you are still interested in.

Well, I can only hope that this is not an official stance.

You are referring to what part of my statement? What part in the help to pijul unrecord was unclear? I’m citing what, I think, conveys the core message. Maybe you have an idea on how to improve the wording:

* With a list of <change-id>s. The given changes will be unrecorded, if possible.

* Without listing any <change-id>s. You will be presented with a list of changes to choose from.

I am referring to the suggested workflow. After unrecording, the patches are still on disk anyway, meaning they can be brought back, or re-applied. unrecord doesn’t have to change at all; we just need something like Git reflog.

The wording is alright. But “delete what you want to keep” is just unintuitive. Maybe that could be made configurable?

Sure, some kind of “garbage bin” might be good to have, I guess. I’ve barely used reflog and just because some actions in git, especially to “repair” branches, are so hairy, that you can lose track of where you are.

I still cannot fathom how you come from “delete a b c” (when written on the command-line) to “when a b c is written in a file, it should actually mean: keep a b c” (when presented with an interactive choice). pijul unrecord has nothing to do with git rebase apart from the fact that they both open a list of changes/commits in a file. Is that what guides your intuition?

EDIT: Now, that I think about it. Is your intuition that you are presented with a list of files, like in a file browser? And that deleting a line should mean “delete from repository”? Is that what guides your intuition?

What is so unusual about the workflow I suggested? What is good about git having at least three different ways to refer to commits? (log, stash, reflog) Why not having it in a single concept if it easily fits into it?

Yes, maybe, some automated “reflog”, which lists recent changes might be helpful. But it could still be handled like a normal channel.

Regarding the “official stance”, the usage pattern of the main author of pijul is “working without any channels”.

I still cannot fathom how you come from “delete a b c” (when written on the command-line) to “when a b c is written in a file, it should actually mean: >keep a b c” (when presented with an interactive choice).

It’s because “what you see is what you get”. That’s how rebase --interactive, but also Mercurial’s histedit, works, and I think that’s good. That’s just how I’m wired, and I am certainly not alone in this.

No one is confused about how the non-interactive command works. I mean, how else could it work.

What is good about git having at least three different ways to refer to commits? (log, stash, reflog) Why not having it in a single concept if it easily fits into it? Yes, maybe, some automated “reflog”, which lists recent changes might be helpful. But it could still be handled like a normal channel.

To be honest, I don’t care. I just want to get the job done.

Regarding the “official stance”, the usage pattern of the main author of pijul is “working without any channels”.

And I guess he also knows how to recover from accidental unrecords.

@MarvinHannott, I have posted a recovery procedure to get UnRecorded patches back, see

#747 UnRecord dangerously inverts Pijul’s UI convention, high risk of catastrophic data loss [+ RECOVERY HOWTO]

The current logic in the UnRecord editor is correct – you select what you want to UnRecord. It should not be opposite like you suggest, this is not rebase or histedit.

However, there is indeed a UI problem, as I describe in the other note, which is that the hashes to unrecord are all selected by default, very dangerous! They should start out unselected (commented out), so you have to explicitly select them in the editor.