The latest trunk of Fossil (20250310184208) looks for suspicious and/or broken hyperlinks in check-in comments and if it find them, give the user an opportunity to continue editing the check-in comment to perhaps fix the problem.

Broken hyperlinks in check-in comments are a persistent problem. Everybody does it from time to time. Broken hyperlinks can be fixed by editing the check-in comment after-the-fact, but we'd like to avoid that.

I'm wondering if this new warning mechanism is helpful or just annoying. Please compile from trunk, if you can, and try it out. Post your feedback below. This feature can be removed if it turns out to do more harm than good.

Can I check that the veracity of hyperlinks is checked only by inspection and not by actually attempting to visit the link (which could cause all sorts of tomfoolery and chaos).

I have no doubt it is the former, but I would like to be reassured.

That depends on the link. External hyperlinks, yes, certainly - it makes no attempt to validate those except for syntax. But some internal links are checked. For example, if you just put a check-in HASH as the link target, it will complain if no such artifact exists in the repository.

If you want to test this yourself, you can run:

./fossil commit --allow-empty --dry-run

The --dry-run option prevents a real check-in, but it will allow you to go through the whole type-in-a-commit-comment process, and the resulting error checking.

Note that I make no claim that the current algorithm is one true and perfect arbitrator of what is and is not a good check-in comment. Far from it. The current precedure just checks for the really obvious stuff. If this concept proves out, we can go back in later and make the validity checker smarter.

The current procedure finds things like:

• Using markdown hyperlink syntax by mistake
• Omitting the ":" in interwiki links such as [forum:/forumpost/feed652201c110e7]

Post your feedback below.

I didn't write because I was happy this didn't affect comments entered by command-line options. Now I'm switching to the "annoyed" camp.

Why? Without known what's annoying you it's impossible to tell if it is fixable or if it needs to be removed.

Why? Without known what's annoying you it's impossible to tell if it is fixable or if it needs to be removed.

For example, I have a project with a module named ENGINE ][ ...

I think programmers seriously making commits to source code repositories can be expected to be familiar with SCM comment syntax and to be careful enough to review their input, no need for all the bells and whistles ...

Because my next fear is that we add an AI interface to verify the contents of comments, and maybe even the checked-in code ... ;-)

You can run:

fossil set verify-comments off

Add the --global flag if you really want to disable this feature everywhere. On your own head be it. Note that the new "verify-comments" setting does not show up in the output of "fossil settings" unless you either use the --extra option, or unless the value for verify-comments is different from the default ("on"). So likely you will be the only person in the world to see it and nobody else will be troubled by the extra setting.

fossil set verify-comments off

Ok, thank you.

It was in no way my intent to trigger addition of yet another setting to Fossil, but you asked for feedback, so I submitted my opinion.

Does the setting sync? And do(es) the other setting(s) for markdown comments sync? Should they? (As the former is a private special setting only for me, it probably shouldn't. But the other(s)?)

BTW: Comments entered through amend or /ci_edit are not checked. Is this by design, or an oversight?

I can understand disabling "autocorrect" spell checkers and I do, but having typos flagged... I've found it to be very useful. Perhaps the software doing the checking won't allow you to add new words to its vocabulary?

After using monochrome code editors for a long time I was blown away with syntax coloring, so many simple bugs have been avoided so quickly. That may be a too cumbersome feature to add to fossil.

syntax coloring... That may be a too cumbersome feature to add to fossil.

It has been done.

It has been done.

See also what is currently the bottom most section of https://sqlite.org/wasm/doc/tip/doc-maintenance.md. That site's embedded docs make heavy use of highlight.js.

Not sure how long it has been possible for, but long enough for me to have read about it a few times

You can use a timestamp to identify a check-in, as long as it is unique (and it usually is). So, for example, the following URLs are equivalent:

• https://fossil-scm.org/home/timeline?c=20250310184209z
• https://fossil-scm.org/home/timeline?c=3e87f78e6019f2eb

Likewise:

• https://fossil-scm.org/home/info/20250310184209z
• https://fossil-scm.org/home/info/3e87f78e6019f2eb

This has been true for time out of mind. But I've recently started using timestamp names more frequently, as it conveys more information about the check-in (specifically how old the checkin is) than the canonical hash.

For best results, use the full the full 14-digit timestamp (though the 12-digit timestamp that omits the seconds also works as of a fix I made yesterday) with the "Z" at the end to indicate "Zulu" or "Universal Coordinated Time" instead of your local timezone.

There are still some issues with this. For example, the timestamp needs to occur at the same instant or after than the actual timestamp on the check-in, not before. So in the examples above, I had to type "20250310184209" not "20250310184208" even though the time shows as 2025-03-10 18:42:08, because the actual time of the check-in is 2025-03-10 18:42:08.506. I need to improve the rounding behavior to fix this, but until I get that done, you can just round the actual date up to the next second. Or even to the next minute (202503101843Z works), if there aren't any other checkins closely following.

Another thing to keep in mind is that the date of a checkin can be modified using the "date" tag. So if you create a link, and then the date gets moved, that link might not work any more.

Check-in 202503181104z improves rounding behavior for timestamp identifiers. After that check-in (which is already installed on the server running this forum), the identifier "20250310184208z" correctly resolves to check-in 3e87f78e6019f2eb even though the timestamp on that check-in is 2025-03-10 18:42:08.506.

Now fixed.