Unrecording a conflict fix is causing cycles

1

Unrecording a complex conflict fix is creating cycles in a file’s graph of lines. After re-recording the fix all further record or revert results in:

thread ‘main’ panicked at 'assertion failed: (left == right)
left: 7833,
right: 1', libpijul/src/graph.rs:659:9
stack backtrace:
7: libpijul::graph::<impl libpijul::backend::GenericTxn<A, R>>::output_conflict
8: libpijul::diff::<impl libpijul::backend::GenericTxn<A, R>>::diff
9: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::diff_with_binary
10: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
11: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
12: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
13: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
14: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
15: pijul::commands::record::changes_from_prefixes
16: pijul::commands::record::run

2

This is using Pijul 0.12.0

3

I would need a way to reproduce. Mind sending me a tarball of the repository?

4

Sure, I’ve sent you a link to it the broken repo.

I’ll try and recreate the state before the problematic unrecord - seems it’s not just a single record on a clone of the broken repo as that causes a different error:

thread ‘main’ panicked at ‘called Option::unwrap() on a None value’, src/libcore/option.rs:345:21
stack backtrace:
9: libpijul::diff::<impl libpijul::backend::GenericTxn<A, R>>::diff_delete
10: libpijul::diff::<impl libpijul::backend::GenericTxn<A, R>>::diff
11: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::diff_with_binary
12: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
13: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
14: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
15: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
16: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
17: libpijul::status::unrecorded_changes
18: pijul::commands::status::run

5

Ok, this is an interesting repository. Can you confirm it was entirely created with Pijul 0.12?

6

The patches were originally created using my fork of git-pijul updated for pre-0.11. The repo has been cloned several times using pijul 0.12. The conflict resolving patches have all been created by 0.12

I’ve recently updated git-pijul to 0.12 and have converted the repo again but haven’t yet checked what difference that makes.

7

Congratulations, I believe you found a bug in Sanakirja! I managed to reproduce on smaller test cases and published a new version yesterday.

1 Like
8

Thanks!

I’m amazed you managed to find anything in that giant morass of conflicts! Any idea when this fix might get into Pijul itself?

9

Well, your repository was corrupted in all possible ways, Pijul doesn’t screw up repositories like that, it had to be something with Sanakirja. Multiple giant branches were not extremely well tested, so I added a few tests to try and reproduce your setup, and that failed quite quickly actually. Don’t know wether it’ll fix your problem, but it certainly fixes one problem you had.