pijul_org / pijul

#153 Unresolvable conflicts in Cargo.lock

Opened by laumann, on August 28, 2017
Closed
laumann commented on August 28, 2017

I'm having major problems with pijul/Cargo.lock. Currently, if I do:

$ pijul clone laumann@nest.pijul.com:pijul_org/pijul
$ cd pijul
$ pijul status
On branch master
Nothing to record, working tree clean

So far, so good. But pijul/Cargo.lock has conflict markers in it. The only resolution I know is to delete the file, and issue cargo build, which works fine. The regenerated Cargo.lock updates nearly every dependency to a new version, which in itself seems fine. The diff is here (btw, I think diff and friends should have a switch to disable coloring, that would make it a little more readable in this case)

I then record the new Cargo.lock:

$ pijul status
On branch master

Changes not yet recorded:
  (use "pijul record ..." to record a new patch)

        modified:  pijul/Cargo.lock
$ pijul record -a
What is the name of this patch? Fix recorded conflicts in Cargo.lock
Recorded patch AQCFjoqU-0D9I5chOtXvfXxzvWbVDdj5yH1hT7-TON9f6iP27UnWB4ZE8l6BF_TQ_dkBBnjFGh6NKGlvl4zFJyM
On branch master

Unresolved conflicts:
  (fix conflicts and record the resolution with "pijul record ...")

        pijul/Cargo.lock

Changes not yet recorded:
  (use "pijul record ..." to record a new patch)

        modified:  pijul/Cargo.lock

Now Cargo.lock is conflicted! But it wasn't before? What happened?

The problem seems cyclical in nature, because the "unrecorded" changes look like the same changes I just recorded. I can record it again, and get to the same state.

$ pijul record -a
What is the name of this patch? Fix recorded conflicts in Cargo.lock (again)
Recorded patch AUKusawwU_frZmIfQRxePI8Jx1LGQYcvRZSGrDBKAM8wYlTQl1pyIFxx8LVNEchSwTti963dvES_8Hsc5gMUqsM

This is quite concerning, and quite a blocker for development in my opinion.

Furthermore, I cannot unrecord the patches. They generate a stack overflow:

$ pijul unrecord --patch AUKusawwU_frZmIfQRxePI8Jx1LGQYcvRZSGrDBKAM8wYlTQl1pyIFxx8LVNEchSwTti963dvES_8Hsc5gMUqsM

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
[1]    30766 abort      pijul unrecord --patch

which is also very concerning.

I'd love to help resolve this issue, but I'm not sure where to begin. I recorded the output of RUST_LOG=debug anu unrecord .... You can find it here - I zipped it, because it takes up 116M unzipped.

laumann commented on August 28, 2017

I generated the dependency graph (thanks @lthms !), and looking at the conflict-fixing patches for Cargo.lock, they all have a lot of dependencies. Maybe a bug in the dependency identification?

lthms commented on August 28, 2017

Glad you could use the dependency graph (: A a side note, you could have get a lot smaller patch by using the following command: pijul show-dependencies <patch> --depth 2 for instance. For the record, I had similar observations with Cargo.lock.

lthms commented on August 30, 2017

AFAIK, a work-around is to record a first patch that removes Cargo.lock and a second one that adds it again to the source tree. That does not prevent the situation from happening again, though.

laumann commented on August 30, 2017

@lthms Thanks for the tip. I have these two patches that I cannot add to the issue:

lthms commented on August 31, 2017

Considering the current state of the pijul repo, using an upstream pijul, one can fix the conflict by doing the following three time: pijul record, then y, then some patch name.

laumann commented on September 1, 2017

Just an update. It looks like Cargo.lock has been fixed (at least it appears with no conflict markers).

I did a fresh clone of pijul_org/pijul, but I get this Cargo.lock, so I'm still seeing this problem.

lthms commented on September 1, 2017

You probably need the latest pijul possible for the clone to work properly, right?

pmeunier commented on September 1, 2017

I had not pushed the right patches. Can you clone pijul again? Sorry about that whole story. At least we know what to test now.

lthms commented on September 1, 2017

With the latest patches, it works! Congratulation on this one.

laumann commented on September 1, 2017

Can confirm that it clones fine, no conflict markers and builds as expected. Thanks!

laumann commented on September 1, 2017

Can confirm that it clones fine, no conflict markers and builds as expected. Thanks!

laumann commented on September 1, 2017

Closing.