Recently, I have wrote help on all subcommands, and it’s time we write the help for each individual arguments.

I am currently working on this. I will push changes to this discussion for review, once I am done, I will squash them and it could be applied

Thanks. But I have already written docs for that file (actually I have written upto debug.rs). You could continue from after that if you want

I am not super familiar with the git subcommand. @loewenheim, could you please write docs for it

I was writing docs for the pijul/src/commands/record.rs file. But I couldn’t understand some of the argument fields like stdin, tag, prefixes.

Could someone help me out here

Alright. I have written most of the help for each argument except for the once I told above

Could you please review it @pmeunier

I can finally ask to apply this once help for the Git subcommand’s argument and others are written

@lowenheim: I’ve applied your change.

@arijid79: This sounds awesome, thanks for your work! This needs just a tiny bit of extra work before I can review it, let me explain. I made a mistake a while ago, and I apologize: I needed to clone my repository of Pijul, and forgot to copy the hooks on record, which included cargo fmt. But then when I put them back, I pushed a big change with all the formatting edits.

Unfortunately, that change happened in parallel to yours, and it seems you recorded a few formatting comments along with your change. I don’t think this is too hard to fix: just run pijul record --amend TXCMJ, delete the sections that aren’t your intended comments, and push to this discussion again.

I’m super sorry about this story, hopefully libpijul will soon be stable enough that I can keep a single clone forever.

Hey @pmeunier, I removed all the formatting that could cause conflicts. Plus I have removed changes to pijul/src/commands/change.rs which @loewenheim had already wrote and could cause conflicts

Thanks, I can see that. I was actually reviewing the messages :-) Nice work, I’ll check everything and push in a little while.

This is impressive work, and is also the first change that must be tested by a human rather than by the compiler. It is also massive in breadth, which explains why the review is a bit long. Thanks a lot! We’re almost there!

• So, repo_path is “set the repository in which paths must be added” for all commands. If you want a generic one, that would be “set the repository in which this command is run”.

• In reset, dry-run actually prints a single file to stdout, and change doesn’t do that (see #95).

• There are a few typos (“wroking copy” instead of “working copy”).

• In record: (“to this value” can be removed, in multiple options), the signature of -S is done with the default SSH key, stdin should be removed (you can do it in your change), prefixes has no documentation (should be “paths in which to record”).

• In pushpull: “omitted” instead of “omited”. “Do not check for certificates” should have a mention “(HTTPS only, dangerous)”, path should be “push only changes related to these paths”. the --to-channel argument is “push to this channel instead of the remote’s default channel”. pull has multiple occurrences of the same typo (“necessorily” instead of “necessarily”).

• The protocol subcommand is not meant to be run directly by the user, but called over SSH. This could be mentionned.

• log: --states is “include state identifiers in the log”. --description is “include the full change description”.

• fork: what --change does is, it forks a channel and applies this change and all its dependencies.

• I don’t think debug needs to be documented, it’s going to change quite a bit, might be removed at some point, and isn’t even compiled in release mode.

• credit: “The file to annotate” rather than “show the annotations”.

• clone: typos, “repositoru” instead of “repository”, “close” instead of “clone”. “Clone this path” should be “Clone this path only”. Use the same warning as in my comment above for -k, “Do not check certificates”.

• archive: typo “current channe;”. remote never clones the repo, it asks the remote to send a tarball. Use the same warning again for -k. --state means “Archive for this state”. For --change the same as #95 holds (pijul can never rely on the order of changes on a remote, but “states” are immune to reordering). prefix prepends a path in front of each path inside the archive.

• apply: --channel applies change to this channel. Maybe add “, not the change itself”. For the argument (field change), you could add that if this is not given, this command takes its input from stdin.

Yeah. I know there are some typos and incorrect/incomplete documentation. When you have so much to write, typos are a common thing. You also have to take my grounds into consideration as there was no previous documentations (There is the manual, but it’s quite outdated) so I have mostly written everything by experiments.

Anyway I am gonna change what @pmeunier have suggested

Yeah. I know there are some typos and incorrect/incomplete documentation. When you have so much to write, typos are a common thing. You also have to take my grounds into consideration as there was no previous documentations (There is the manual, but it’s quite outdated) so I have mostly written everything by experiments.

Absolutely, and my comments were not a criticism at all! I totally appreciate the amount of work this represents, especially without prior documentation, and with little guidance from me. I’m super impressed and really happy to see great contributions like this happen.

Alright. I have added all changes you have suggested. Could we apply this @pmeunier

If it’s confirmed. I will squash and republish the changes

Applied! I’ve also updated a few things. Thanks.