The sound distributed version control system

#868 surprising behavior of `pijul apply`

Opened by kimme on January 14, 2024 Good first bug
kimme on January 14, 2024

So I’ve started using pijul for a personal project (at beta 6, latest boringcactus’ build).

I have a ‘stash’ channel that holds some more or less random snippets (commutation rocks btw, wouldn’t dream of using git stash this way). As it happens, I’ve stashed a - so far unused - function there the other day. As I was hacking away, that function started to come in handy, so I proceeded to get it into the main channel again.

Maybe pijul apply <hash> wasn’t the right choice of command… I got that function back just fine, but it also undid all the unrecorded changes in my working copy across several files unrelated to the change!

No harm done, I still had the day’s work in my editor’s undo buffer, but maybe pijul could do a check for unrecorded changes, or even better, not touch unrelated files at all? Coming from git I didn’t worry too much beforehand, as git would just have refused to touch a dirty working copy. I didn’t have changes in the one file affected by that change.

I did think about using pull, but its kinda weird that it can work with remotes as well as local channels and apply seemed like a perfect match for a single patch.

Keep up the good work, I can’t wait for the day I can introduce pijul at my day job!

pmeunier on February 7, 2024

Yes, this is not very hard to fix, and would stop me from lying in talks where I claim Pijul has three commands (record, apply, unapply). pijul apply is indeed meant as a low-level command, but you’re totally right that it should at least print a warning.

Here are the steps to fix it:

  • Study pijul/src/commands/pushpull.rs, especially around the pending patch.
  • Then refactor that together with pijul/src/commands/apply.rs.
pmeunier added tag Good first bug on February 7, 2024