rns.recipes

I saw that you often reply to posts, so I thougth this would be the easiest way to contact you, while provinding the ability for community to discuss it if it is needed.

Sometimes it is included, sometimes not, and each time it is, it is bundled as a binary blob that, as I understand, will change on every recompile, and is probably not easely reprodusable.

So my question is, do you intend on the keeping builded versions of manual in the git tree, and is it a good decision?

Sorry for post-duplecation, I yet again entirely forgot, that reload in nomadnet resends the data

I am personally against committing the PDF to the repository. Git is generally not a good fit for storing generated binary artifacts, since they do not diff meaningfully and can cause the repository history to grow unnecessarily.

However, I do think the PDF manual should be treated as a release artifact: generated from the source at release time and attached to the corresponding release.

That said, GitHub does not seem to be the project's primary repository, so the preferred release workflow may be different.

It does increase the size of the repository and syncs quite a bit since the PDF + EPUB is around 8 megabytes. I initially included them because I think it's quite essential to have, but now with all the historical versions, it's getting a bit cumbersome.

I might shift it over to only having the sources and then also the markdown version available in repository tree (which it is now). That way, there is at least always a somewhat decently formatted manual available in every repository clone.

The best practice currently for getting the actual manual PDF and EPUB is to fetch them from the latest release, for example using:

rngit release rns://7649a50d84610232d1416b41d2896aff/reticulum/reticulum fetch "latest:Reticulum Manual.pdf"

I kinda want to rewrite the repository history to remove all the old binary blobs, actually, since it's annoying for people to have to clone 100 MB or so, for a codebase that'r realistically only around 15 MB, including all the actual code history.

Just really irks me not to have all the commits be completely historically consistent, though.

While I generally firmly oppose rewriting the history of a widely used project, for obvious security reasons, I have to admit that removing the old binary blobs would be great.

Thinking out loud: perhaps we could use this opportunity to rename master to main, and apply the rewritten history only to the new main branch ?

p1ld7a wrote:

While I generally firmly oppose rewriting the history of a widely used project, for obvious security reasons, I have to admit that removing the old binary blobs would be great.

Thinking out loud: perhaps we could use this opportunity to rename master to main, and apply the rewritten history only to the new main branch ?

The default rngit HEAD reference is master

Change sha-1 to sha-256 in git

zloto wrote:

Sorry for post-duplecation, I yet again entirely forgot, that reload in nomadnet resends the data

Don't worry about it btw, I had meant to fix that ages ago. Will fix that tonight during maintenance

what is the best interface to connect to the main rngit repos?

Third Force wrote:

what is the best interface to connect to the main rngit repos?

Any client that supports NomadNet pages if they have that enabled, and just standard git for any remote

This thing is annoying too.

docs/manual/objects.inv | Bin 3178 -> 3178 bytes

Looks like objects.inv is an artifact of make http, and should not be included in git