Once again, thanks for the report. In this case, this is expected behaviour, because you’re essentially simulating the situation where Alice and Bob both create a file with the same name, which is a conflict.
But maybe there is a more reasonable behaviour, what were you expecting? Would it be more intuitive if we refused to apply the conflicting patch, rather than outputting the conflict?
My standard expectations from any software no matter what I did wrong:
I’m planning on adding a whole lot of feedback about conflicts, so that should solve your first point. In the theory, conflicting states are not treated as errors in Pijul, they’re the normal thing, and I understand this can be confusing in practice, especially without feedback.
About your second point, how do you think we should represent the situation to the user? Would you find it more reasonable to receive an error message, and have an option to force the output?
Also, Libpijul has an option to avoid outputting that sort of conflict (file name conflict), so the fix for that particular bit will probably take one or two lines of code.
About second point - this is also silence rule:
`Info:` new tracked file(s) have been added on destination channel.
I’m reopening in order to remind myself to implement the verbose commands.
C4MJ7D7QCOFGIHQSDV3UC76DTSE5M7JSLGN5MROMSVKFVQRFSP5QC
This was actually super easy, but I’m glad it’s done.
Short: it adds collision to tracked fails after my illegal steps.
Preparing sandbox:
I seen situations when collision was added to tracked files
on both
channels - main and m.I repeated this several times, but failed to create 100% repeatable scenario here in report.