The sound distributed version control system

#700 [FEATURE?] why conflict returns automatically?

Closed on February 27, 2023
tankf33der on July 20, 2022

I am writing tricky test scenario to test conflict which fails.

  1. Why this conflict returns again and again?
  2. What is correct steps to resolve this type of conflict?
$ pijul init p1
$ cd p1
$ touch a
echo "1" >> a
$ pijul add a
$ pijul record -am"."
Hash: SUXHOIT3YGJOYDGZMHEXK3GBFOJUWOL4HNU7DZSISKYKJQ7GKCPQC
$ pijul channel new m1
$ pijul chann switch m1
$ echo "2" > a
$ pijul add a
$ pijul record -am"."
Hash: WVCVJFJ4BIF3MFRQAG52VOIKPJO2D2TF2HVGTJQPJXNGLQUUMJMQC
$ pijul apply WVC --channel main
$ pijul channel switch main
Outputting repository ↖                                                                                                                   

There were conflicts:

  - Name conflict on "a.WVCVJFJ4BIF3M"
# i have invent these steps to remove conflict
$ pijul remove a
$ pijul remove a.WVCVJFJ4BIF3M
$ rm a
$ mv a.WVCVJFJ4BIF3M a
$ pijul add -r .
$ pijul diff --short --untracked
A,D   a
$ pijul record -am"."
Hash: W4KLZ3W64GUR4HKAZSXLXCMJK3T7AARXANGYY3EUXBY4UKGNIJVQC
$ pijul channel switch m1
$ pijul channel switch main
# conflict push back
Outputting repository ↖                                                                                                                   

There were conflicts:

  - Name conflict on "a.W4KLZ3W64GUR4"
$
tankf33der on July 25, 2022

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).
$
tankf33der on July 25, 2022

Did not help, in my complex test scenario conflict returns anyway.

pmeunier on February 27, 2023

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!

pmeunier on February 27, 2023

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.

pmeunier added a change on February 27, 2023
YK7EBTF6LAPMYEHPPOUKHO3IQTA4MTKOEI77I4UWXTM4T475QKRAC
main
pmeunier on February 27, 2023

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.

pmeunier closed this discussion on February 27, 2023