The sound distributed version control system

#674 re-record dependencies after unrecord, and reverting patches

Opened by MarvinHannott on April 23, 2022
MarvinHannott on April 23, 2022

It has been discussed before that dependent patches can be a pain when trying to unrecord a patch. But what about a new flag for unrecord like rerecord, so that all dependent patches are also automatically unrecorded, but then automatically re-recorded (with the same meta-data)? Of course that requires user intervention like in Git’s rebase, but it would nonetheless result in a much better workflow than having to unrecord dependencies manually, which is also error prone.

It would also be cool to be able to revert a set of patches.

spacefrogg on April 26, 2022

I am also in favour of allowing unrecord of dependent changes. Though, this would make it a much more powerful command than it already is. It could come with a safeguard that checks if all of the affected changes are still in a local channel, like git branch -d.

Also, yes to revert, although it could be tricky to identify the correct meanings of all the types of modifications that a change represents.

The information you need to “rerecord” an arbitrary set of dependent changes is exactly what is stored inside a channel. Not only does it store the changes, but it also maintains the log which is your only way to find them again. “rerecord”, then, is synonym to pull because the second channel keeps your full repository state plus the changes you unrecord’ed. Pulling them adds back exactly those changes and nothing else.

Right now, push has the weakness of not automatically pushing dependencies. For the sake of the workflow you laid out, it would greatly help if it would. You would push your changes (and only their dependencies) to said second channel to keep them; unrecord them; and pull them back if you need them by referring to the log of the second channel.

There is a workaround for push. You can use pull “from the other side”. So apart from unrecord. All the tools are already there.

Example: You have a channel chan-A with the following set of changes ε <- a <- b <- c ; ε <- d <- e ; ε <- f. (Changes separated with ; are independent of each other.)

Suppose, you wanted to unrecord the set d <- e. You would run pijul channel new keep-stuff; pijul pull --to-channel keep-stuff . -- <hash-of-e>; pijul unrecord --reset <hash-of-d> <hash-of-e>.

Later, when you decide to get them back you would pijul log --channel keep-stuff; pijul pull . --from-channel keep-stuff -- <hash-of-e>.