pijul_org / pijul

#299 recover patches lost to unrecord

Opened by bmurdock, on August 27, 2018
Open
Question
bmurdock commented on August 27, 2018

I just started playing with pijul. I created a new repo for a simple script I'm working on and made 3 patches as I worked. After creating the last one I immediately wished I had used a better message/name to go with the commit. "No problem," I thought, "I can use unrecord." I typed pijul unrecord and then without thinking too hard I hit 'a' thinking it was asking me for hunks in the patch. I then quickly typed pijul record -a and typed the better message/name. I then typed pijul log to admire my work and realized I had unrecorded all my patches and created a new one that is a combination of them all. Not a big deal, I'm just toying around, however, I noticed that down in the .pijul/patches directory my original patches seem to still exist as separate files there. Is there a way re-import those?

pmeunier commented on August 28, 2018

Hi!

Thanks for the feedback. There is actually a way to reimport them, but it's a bit hackish. I just successfully did the following:

pijul apply $(basename -a -s .gz $(ls .pijul/patches/*.gz))

Feel free to close if that solves it for you, and thanks for your interest!

pmeunier commented on August 28, 2018

By the way, if you can think of a better "first use" experience that could have prevented your problem, feel free to chime in.

pmeunier added tag
Question
on August 28, 2018
onio commented on August 28, 2018

I think that option (a in unrecord) has no real value, it just adds a misuse/"typo"/brainlag-risk.

bmurdock commented on August 28, 2018

Thanks! That seems to have worked. I kind of agree with onio, that maybe 'a' is a little too drastic of an option to provide to unrecord. I only had 3 or 4 patches, but in a mature project with hundreds or thousands of patches unrecording all would never be what someone wanted to do.

Now, if it fit my first assumption that unrecord was going to offer hunks of a single patch to select just like record does then that's a different story. An 'a' option there would make a lot of sense.

I'm really hopeful that pijul takes off, I really like the concept!

lthms commented on September 4, 2018

I would really like to have a notion of… well, I don't know how to name it. But basically, some kind of set of patches, known by pijul but not applied to the current branches, that we could work with.

Maybe we could have a special branches that would contain all the patches that pijul know of. And, we could propose a command to clean-up this kind of patches graveyard.

Also, we could pull patches from a remote directly to this place, so it would be available offline, but we don't need to have it applied somewhere.

pmeunier commented on September 4, 2018

But basically, some kind of set of patches, known by pijul but not applied to the current branches, that we could work with.

Like for instance we could call that the external/internal tables, in which case that thing would already be there!

lthms commented on September 4, 2018

Well, it is even better if the only thing that is missing is the CLI, for sure \o/.