Pijul

Putting generated files into a repository

Question
#1

Yesterday I ran cargo update and then cargo build. It downloaded some updated crates and was building pijil, when almost at the end, it errored out and I realized I had not pulled down the latest pijul. Cargo had output that it was waiting for some processes to finish. So I typed in pijul pull and it showed some changes. I used Ctrl X to exit the editor (I still don’t like that interface!) and it completed.

When I tried cargo build again, it immediately said there were invalid characters in Cargo.lock. I looked at the file, and sure enough, there were lines of <<<<<<<<<<<< and ------------------- looking like conflict markers. I tried pijul pull again, but it said there was nothing to pull.
So I went to the Nest and looked at the file. It’s crazy that it’s 2559 lines! I copied that one to my local copy, and the build worked fine. (by the way, the Nest doesn’t have any easy way to copy a file)

So my question is, why was that file corrupted that way? I know it’s dynamically generated, but did Pijul not detect the difference between the local and remote?
And why is that file so big? (there are multiple versions of lots of crates referenced in there)

#2

Good question. Indeed, generated files are likely to be in conflicts at one point or another. This is because it might get updated by multiple authors, including yourself (automatically) when you run cargo build.
That file contains the version of all the transitive dependencies of Pijul, and there are many dependencies. This is because (1) Rust crates tend to be packaged in smaller portions than in other languages, possibly because cargo is very well designed, so there is no real incentive to write “swiss army knife libraries”, and (2) Pijul does a surprisingly large amount of things, ranging from database storage to network protocols, with some algorithms in the middle.

#3

I forgot to mention the solution for you: pijul reset Cargo.lock should do it. You can also regenerate the file yourself by simply deleting it.

#4

Would another solution be to use .ignore for that file?
My concern was the general case, in which Pijul’s pristine didn’t match the working folder (or did it?) and the pull command didn’t change anything.

#5

No, because we need the lock files to be recorded in some cases, to give a working solution to dependency resolution.

Pull merges remote changes into your local repository. What you’re looking for to “sync” is pull + reset.