I’d just fossil set autosync off in this condition.

Plan B: sync to a more reliable local server and cron a sync from there to the dodgy remote. This gets you off-machine backup while the robot pounds mindlessly thru the damage until it achieves off-site backup.

Thank you, both good options.

Check-in e8a21ab43c775a67 adds the --nosync option to the "fossil commit" command.

Aside:

There is inconsistency in the options. Some options that start with "--no" have a dash separating the "--no" with the word that follows and some do not.

Options without - after "--no":

• backoffice --nodelay
• backoffice --nolease
• branch new --nosign
• branch new --nosync
• http --nocompress
• http --nodelay
• http --nojail
• http --nossl
• rebuild --noverify
• rebuild --noindex
• ui --nobrowser
• ui --nocompress
• ui --nojail
• ui --nossl

Options with - after "--no"

• changes --no-merge
• changes --no-classify
• commit --no-warnings
• commit --no-prompt
• commit --no-verify
• clone --no-compress
• clone --no-open
• grep --no-messages
• import --no-rev-tags
• import --no-rebuild
• import --no-vacuum
• pull --no-http-compression
• push --no-http-compression
• sql --no-repository
• sync --no-http-compression

I've already complained in advance when there was a discussion about --dry-run vs. --dryrun, but this time I'm more concerned: quite a few of these options appear in my scripts (a full terminal screen's worth of output) and also in my private patches. So I'd appreciate if both versions could be kept for compatibility?

Thank you for the new feature! Kudos!

I have thought more than once than a --nosync flag would be useful. I look forward to trying it out.

I was not suggesting that we change anything. I was just observing the unfortunate inconsistency.....

I'd be advocating for a fix if it wasn't so nearly fifty-fifty. If one was a clear winner, we could shift over, but as it is?

The best idea I have is to abstract "no" handling as a tristate return from the option checker, where defining an option like "--nossl" implies that "--no-ssl" and the no-op "--ssl" options also exist. (The states would be true, false, and unset.)

I expect this would have to be done on a per-instance basis, since not all current Boolean options would make sense in a tristate form.

Making sure there's a way of defining an option like --note that does not accept --no-te and --te.

Thank you, much obliged.

I like consistency. I'd advocate for the dash version, maybe biased by gcc - of course, keeping the no-dash (sic!) variant for compatibility where it currently exists.

If the

--no-worries-bro

version was canonical, presumably it's not an issue to accept the

--noworries-bro
--noworriesbro

versions as long as they are unambiguous.

And presumably such ambiguity is easy to spot by comparing collapsed versions of the options.

I'm aware fossil already detects ambiguous short commands, and accepts minimal truncated commands if not ambiguous.

I'm aware fossil already detects ambiguous short commands, and accepts minimal truncated commands if not ambiguous.

It can do that for top-level commands because those get compiled in to a shared top-level data structure as part of the build process. Subcommands and command-specific flags are handled in a more more "Wild West" style which would require an exceptional amount of surgery to rewrite for the 110-ish available commands (not counting the 149-ish test-* commands, most of which accept arguments as well).

We could maybe get away with teaching the CLI option handler to special-case anything starting with "no", to accept "no-" as well, and vice versa, but that sounds like a slippery slope. Patches would be thoughtfully considered.

Ah. Frankly then I don't think I'd bother in that case.

The risk of some missed, unpredicted option like --note or --none=xxx popping up and catching people in the far future isn't worth it.