see also: git2 crate …

What’s wrong with what it is now? If you open https://docs.rs/libpijul/1.0.0-alpha.34/libpijul/trait.MutTxnTExt.html

You will get a list of methods on the left of the screen. Now, none of these are documented, and the trait could have a few more methods (for example stuff to deal with files and directories could be there instead of in the fs module).

Ok, most stuff is fine, actually, I’m just a bit unsettled by the fact that the implementation of some commands is really big and complex, e.g.: https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.B62AC https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.P6GQC https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.OJ6QC https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.QE3QC

Additionally, I would think it would be a good idea to split to lock’s impl’s (https://nest.pijul.com/pijul/pijul:main/JL4WKA5PBKXRM.SQDQA) into another crate, as they might be benefitial to any application which wants to interact with pijul repos, but not necessary (e.g. if the program does locking via another mechanism), and it doesn’t really “feel right” that that part is not more separated from the rest, as it seems to be pretty isolated per concept/dependencies.

The lock command is almost dead, it will be replaced by something in libpijul in a matter of hours/days (it is already dead on my local repo).

Other commands are a bit complex alright, maybe we could rebalance a bit with libpijul, or split them into their own crate. They’re really just glues between libpijul methods.

@ammkrn’s work on remotes has already resulted in a massive improvement on function sizes in the modules you cited. Also, work on the protocol isn’t completely done yet, I’d like to add a HTTP/3 backend in Pijul, in addition to SSH (and drop SSH on the Nest).

When that happens, it might cause a split between a protocol crate and the Pijul crate. However, the protocol is now too tightly coupled to Pijul that it wouldn’t make much sense to split it, and could cause extra friction.