I found the correct (?) combinations of steps for conflict resolution, it does not return now.
$ pijul init p1
$ cd p1
$ touch a
$ pijul add a
$ pijul record -am"."
Hash: N2HLC222D5HURJT5DPZ7KXEFN6REV7GZF2UM62FNXJMZ7AAJ363QC
$ pijul channel new m1
$ pijul channel switch m1
$ echo "mike" >> a
$ pijul add a
$ pijul record -am"."
Hash: DZCZAWSUUGJCNXMUJNHNLSB4QKWX67LJH75NYDZTFHDRQAHKZEXQC
$ pijul apply DZ --channel main
$ pijul channel switch main
Outputting repository ↖
There were conflicts:
- Name conflict on "a.DZCZAWSUUGJCM"
$ pijul remove a.DZCZAWSUUGJCM
$ rm a
$ mv a.DZCZAWSUUGJCM a
$ pijul record -am"."
Hash: LS2K3P2IIEYDJR6WGLFHW7WFTNDF5MCBPAS4K4ZAGVWTFHQRAXUQC
$ pijul channel switch m1
$ pijul channel switch main
# No any conflict(s).
$
Did not help, in my complex test scenario conflict returns anyway.
This is an actual bug: your first example is not a very natural way to solve a conflict, but we shouldn’t care, Pijul should work regardless of how “natural” things feel to Pijul’s author.
Here, if you remove the -am.
in the last record, you see that file a
gets added twice, which means this patch conflicts with itself!
Oh wait, it’s actually more complicated. By creating a new channel from scratch, you’ve also created a new, independent root. And actually, in both of your examples, the first unnamed patch in each of your channels has a different hash.
When you’re applying WVC in the first example, or DZ in the second, you’re merging two completely unrelated file hierachies that both happen to have a file named “a” at the root.
I believe I know how to implement the safeguard.
YK7EBTF6LAPMYEHPPOUKHO3IQTA4MTKOEI77I4UWXTM4T475QKRAC
This is fixed. To run into this scenario again, you would have to use --empty --force
in pijul channel new
, which is unlikely to happen unintentionally.
I am writing tricky test scenario to test conflict which fails.