Can't resolve conflict with zombie

Question
1

Every time I pull new changes this conflict comes back. It’s conflict structure looks like:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
foo
================================
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
bar
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

That “bar” line is a zombie. I want to keep “foo”. But editing the file for that leaves no changes to record.

I made the mistake of unrecording the patch where the zombie came from and now my repo is broken with this stack:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value'
...
   8: libpijul::optimal_diff::delete::<impl libpijul::backend::GenericTxn<A, R>>::delete_edges
   9: libpijul::optimal_diff::delete::<impl libpijul::backend::GenericTxn<A, R>>::delete_lines
  10: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>,     R>>::diff_with_binary
  11: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
  12: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
  13: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
  14: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
  15: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
  16: pijul::commands::status::run
  17: pijul::main

Luckily a clone sorts that out.

2

Do you think you can provide a script to reproduce? This shouldn’t happen, Pijul was designed to avoid our frustration when reverting/resetting/unrecording conflicting states with Darcs and Git.

3

Well the good news there is that I came to Pijul because this same source caused Darcs to corrupt itself when applying the patches.

I’ll try and recreate the issue but the essence is multiple “cherry-picked” patches in both directions between two branches where the patches were sometimes edited slightly during the “picking” (due to them originating from a Subversion repo).

4

Another thing you can do is send me a tarball of your .pijul, that would be very helpful. Btw, is this something you tried with Pijul 0.11 only, is this older, or a mix?

5

The Pijul repo was created using my fork of git-pijul which was built against a recent pre-0.11 version. So one thing will be to update that to the released libpijul and reconvert.

Otherwise I’ll try and reproduce it with a small example because the problematic db is over 1Gb.

6

Well I’ve not been able to reproduce this in 0.11 using the problem file and patches and manually copying the changes over to a clean 0.11 created repo.

I think the latest conflict fixes may be what I need as I managed to corrupt another clone of the problem repo by pulling from only one of the branches which suggests that the existing patches are the issue.

7

Great news. There was a pretty nasty bug in the code that output files, mostly for conflicts. The algorithm was completely wrong, rested on wrong assumptions and did not do the right thing at all. I’m even surprised it passed the tests, but that was probably because repositories are cleaned after every patch application in the tests.

8

Thanks! Now I’ll have to try out Carnix :slight_smile: