$ pijul init p1 
$ pijul clone p1 p2
$ cd p1
$ touch a
$ pijul add a
$ pijul rec -am.
Hash: LUCKD36XFLIQ7AECZY774KWMK2J7Q3B6NAV7OTUAIAYP2D45WZUAC
$ echo "2" >> a
$ pijul rec -am
Hash: YPTSWQY3SMN2NRXLBJFZRLO4I2DY27XC5STTYN7GE2DFYE6WBP7QC
$ cd ../p2
$ pijul log
No matching logs found
$ pijul pull -a
  Downloading changes [=================================================] 3/3  
             Applying [=================================================] 3/3  
   Completing changes [===============================================] 0/0  
Outputting repository ↖   
$  pijul log --hash-only
YPTSWQY3SMN2NRXLBJFZRLO4I2DY27XC5STTYN7GE2DFYE6WBP7QC
LUCKD36XFLIQ7AECZY774KWMK2J7Q3B6NAV7OTUAIAYP2D45WZUAC
352JUGBE5XMOJEB7JDV4E52TUO27ISU2WE6RE3IQGMXFZZ4M3ZCQC
$ pijul unrec YP
$ pijul pull -a
  Downloading changes [=================================================] 1/1  
             Applying [=================================================] 1/1  
   Completing changes [===============================================] 0/0  
Outputting repository ↖                                                         

There were conflicts:

  - Order conflict in "a" starting on line 1
$ cat a
>>>>>>> 1 [CRZOCQSM ]
2
======= 1 [YPTSWQY3 .]
2
<<<<<<< 1
$ 

Conclusion, two things:

o) maybe duplicate of [#826].
o) where did [CRZOCQSM ] come from?

Is there a missing command or two in your test? (Why would echo "2" >> a result in a hash?)

This is actually (almost) the expected behaviour (but false positives don’t hurt at all!): when you did pijul unrec YP, your working copy differed from your pristine. Had you done pijul rec or pijul diff there, you would have seen + 2 as an edit.

CRZ… is the identifier of the “pending patch”. I agree that we shouldn’t show it, since that patch has disappeared already when outputting the repo. [pending] would be a better way to represent that.

This requires some refactoring of libpijul::output::output_repository_no_pending.