\o/ CONFLICTS FIXED \o/

I am quite sorry I’ve not been very active in the community lately, that is because I was bothered with a more basic problem: Florent and I had created a conflict to which Pijul was not able to record a resolution.

It is now fixed! Obviously, the patch that fixes the conflict includes code that enabled Pijul to record this very patch.

The bug was in the new refactoring I did in December 2018, where I (1) moved the diff algorithm into its own crate, and (2) refactored the way files were output to the user. These have been in my experience the two hardest things to get right, partly because the problem is ill-defined, but also because any way to output a graph as a flat file editable in an editor will lose information, and defining what can be lost is hard.

I hear the comments about why Pijul should be developed on GitHub before being perfect, but (1) experience has shown that there is no real way to know when it is perfect before we actually use it and (2) writing Pijul has been relatively hard, I would probably lose a significant part of my motivation if I couldn’t use it on important projects.

8 Likes

That’s awesome!

Also, I feel like I now understand a lot more about why you’re using Pijul for Pijul :slight_smile:

tried cloning master branch with pijul from crates.io, got a conflict in pijul/src/commands/status.rs:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
use libpijul::fs_representation::RepoRoot;
use libpijul::status::{unrecorded_changes, ChangeType};
================================
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
use libpijul::fs_representation::untracked_files;
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

tried fixing the conflict, building new pijul and cloning, same thing.
conflict markers don’t show up in nest but untracked_files is still included even though it was removed.

Oops, I totally forgot that you need the latest master to clone the latest master. Sorry about that, I’ll release 0.12 tomorrow.

I did pull master using the master, and I still got the conflict, does the nest have some extra-private patches :thinking:?

I know what happened, and I just fixed it.

In order to test and solve the original problem, I had to copy (not clone) my work directory and try to record in that directory, until I could record a fix to the conflict in pijul/src/commands/record.rs. But because I was always compiling in debug mode, I only ever tried to record that file. When I finally succeeded, I pushed the patch to the Nest after just cloning a few times and checking that file.

The reason I was not cloning is that I wanted to keep the exact same repository that was causing the problem, and I didn’t want to unrecord or apply in a different way, because that could have solved the problem (by removing forward edges, for example).

I was not aware the conflicts were due to a bug in libpijul (although I guess I should have guessed). Great work, @pmeunier, for fixing it!

I was able to build an up-to-date pijul yesterday, so this is a great news! Unfortunately, I did a fresh clone of pijul today and a conflict is present in libpijul/src/fs_representation.rs ):,

On a related note: are you still planning to release a new version of pijul soon?

Edit: Okay, so with a fresh install of pijul from crates.io, it works like a charm.

Yes, I think the current master has substantial improvements over the released versions, such as:

  • Fast diff
  • “Fixed” output, which is not super accurate in some bad cases but handles cases that are even worse just fine.
2 Likes