I had an anonymous checkout, which shouldn't submit any changes.

That's a feature. I not only have clones of repos with local changes that I intend never to push, I've outright recommended it to others for assorted good reasons.

It wouldn't be a distributed version control system if you could prevent people with local clones to do whatever they liked with their local clone.

What you're talking about requires centralization if you want it to stick.

Didn't see any readonly checkout

If there were such a thing in Fossil, it would be a trivial matter to clear it on the local clone, landing you right back where you are now. It'd be about as secure as the old DOS "read-only" flag.

workaround: remove current checkout and do a new clone

Or, workaround 2: tag your local side of the clone as a branch so it is no longer a fork.

Or, workaround 3: mark it as a private branch so the local Fossil instance doesn't try to push it at all. (Tricky bit: do it retrospectively. I'm sure it can be done, but I don't see any UI for it currently.)

If you want to fix this after the fact (without re-cloning), you can always move your checkin to a branch (it will avoid the fork).

If you want to be sure it will never land on the remote server (let say you get permission to push later), you can make this branch private so it will never sync.

Yeah. But sometimes it is nice to have a "safety" that prevents write operations by mistake. Sure, you can always turn the safety off and do a write, but it is an extra step that helps to prevent errors that occur because you happened to be in the wrong terminal or ssh-ed into the wrong machine or similar.

There is already the "dont-push" setting, which if enabled prevents pushes to the remote. It wouldn't be much trouble to add a "dont-commit" setting that raises an error if you try to do a commit that you didn't really want to do.

As you note, in the absence of a builtin option to prevent accidental commits, hooks are a great solution! For future accidents, however, there is an alternative to the trash-and-clone-again fix.

The following suggestion utilises an experimental command that is neither used nor recommended by most Fossil developers and comes with the following warnings:

WARNING: This command can potentially destroy historical data and leave your repository in a goofy state. Know what you are doing! Make a backup of your repository before using this command!

FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.

Nonetheless, the command exists and I've used it for much the same reason.

If you have not made any additional changes to the repository since the accidental commit, you could purge the offending commit:

$ fossil up prev
$ fossil purge checkins `fossil timeline next -F %H -n 1 | head -1`

This will remove the OFFENDING-COMMIT and all of its descendants. IFF you have not made any changes to the repository since the accidental commit, obviously only OFFENDING-COMMIT will be removed.

For any readers looking to fix accidental commits, please take heed of the abovementioned warnings and at the very least make a backup!

It wouldn't be much trouble to add a "dont-commit" setting that raises an error if you try to do a commit that you didn't really want to do.

I think that's a really good idea.

I can't say I'm morally opposed to this. It might even be good to have the flag on by default for anonymous clones, so that weirdos like me who currently make use of the local private fork capability have to turn it off, effectively saying, "Yes, I know what I'm doing."

The setting has just landed on trunk under the proposed name dont-commit.

Purging a local commit like this before it's pushed is pretty much what the feature was created for. Only the original context motivating it differs, being that you've integrated a bundle someone sent you for testing and have decided not to publish it after all.

Good call-out.

Yay!

How about enabling it by default for anonymous clones, per my post #8?

I guess it depends on how many weirdos gather around. Let us listen.

If it stays silent, you must unfortunately type your fingers out and say "fossil set dont-commit on" each time. Or script it 😄.

You've inverted the sensible condition. The nature of weirdos is that we're in the minority, so our wish to have anonymous clones that we can still commit to is the rare condition. Cater to the masses, not to us weirdos.

How about enabling it by default for anonymous clones, per my post #8?

Perhaps running the "remote-url" command with an explicit user name should implicitly disable it?

Just spitballing.

We can always add another (global) option that says whether (for anonymous clones) dont-push gets enabled 😅.

Stephan: it might make sense iif we decide in favor of default enabling it. I am rather disinclined thereto.

I think this is a case of "sensible defaults." If you clone anonymously, you probably never intend to commit anything; it's almost always an error. You should have to go out of your way to say, "Yes, really, I'm not kidding."

Yes, that's another case of sensible defaults. By assigning a new remote URL, you're saying, "Now I'm going to commit to this repo I previously cloned anonymously."

ssh://hostname/fossils/project.fossil

That only works for repos under your control, though. It's happened more than once that a new fossil contributor, after sending their CLA to Richard, wants to push changes they've made locally but couldn't previously push. For the main fossil repo, CGI/https is the only connection option, and "remote-url" is the easiest way to "upgrade" their previously anonymous checkouts.

So maybe the automatic "no commit enabled" should only apply to anonymous clones over http(s) and not to clones over ssh?

Maybe it's just me, but when cloning not-my-own repository I rarely have a desire to commit changes to my clone, and when the need arise switching off this flag is not really hard too...