before-commit

When a before-commit hook script becomes fired I miss the typed in comments from the command line parameter -m respective the editor input from temporary file.

The file commit-description-xxxxxxhashxxxxxx.txt file lists the affected files etc but the comment text is missing. How does a hook script can access also the comment text from the fossil commit command?

after-commit

No such hook type yet exists. There is needed a second instance to fire a after-receive hook script instead to get after-commit activity initiated, which does not make sense without repository distribution. Could there be either such an additional hook type added or the existing after-receive hook type also fired after local commit succeeded (before sync activity)!?

The current implementation invokes before-commit before prompting the user for the checkin comment. So the checkin comment is not available.

Do you think the before-commit hook should fire after prompting for the user checkin comment instead?

Are you (MBL) willing to become our official hook-stress-test contact person? :-)

Using commit hooks from other systems (cvs, svn) I have used it for:

1. validate code changes
   1. acl for critical files (only certain people can commit a change)
   2. automatic syntax checks of the files to be checked in (sh -xvn must pass on shell scripts)
   3. validate formatting (no tabs in python code please)
   4. verify documentation (e.g. checkin must include change to ChangeLog file).
2. documentation of checkin (comment)
   1. verify that a ticket id is referenced
   2. require other meta-data in checkin comment (e.g. subject line and detailed notes ala git)

to do this requires a way to access the checkin comment and potentially compare it against the files that have been submitted before the commit is added to the blockchain.

Some of these may not be possible in a distributed environment. The only choice may be to delay failure detection to the CI/CD step and then try to figure out how to notify the miscreant that they broke things.

In a distributed SCM, the check-in occurs on the user's local machine. The user is in complete control of that machine and all of the software running on it. Hence, that user can do whatever he wants. Commit hooks can be used to validate commits, but those are advisory only. The user can always turn them off or change them, since he controls the machine. Such hooks serve to prevent careless errors, not to prevent malice.

This is consistent with the overall design philosophy of Fossil. Fossil is intended to allow you (as a user with check-in privilege) to do whatever you want. Fossil does not enforce workflow restrictions or design rules. Fossil might warn you of violations, but it is up to you to follow the rules. Enforcement is the domain of external administrative processes.

The idea here is that you should trust your developers. Do not give check-in (or push) privileges to anybody whom you do not trust. This is as it should be in a civilized world.

Of course, sometimes people will prove themselves untrustworthy. For that reason, Fossil maintains an immutable audit trail and powerful reporting tools so that misbehavior can be detected and corrected. But the design assumption is that misbehavior is rare and developers will voluntarily follow project guidelines and best practices.

I was thinking about the best way to make comments available to the hook scripts.

before-commit and the source of the comments

Currently I know about 3 ways of providing comments.

1. committing straight will open an editor and a temporary file is created. The name of this file could become passed through like %R %F %A are already; I suggest %M for the file containing the comments.
2. committing with usage of the -m TEXT parameter; I suggest to save the comment into a file and pass the file name via %M substitution of command line parameter (like in 1). Getting the one-line-comments double (in commit-description-xxxxxxhashxxxxxx.txt and in the temporary text file) would not harm and could also simplify the hook scripts activities.
3. add another commit parameter option to provide the comments per file name; I suggest fossil commit -M FILENAME for this purpose Edit: I found this in the fossil commit help text already and it is working. ( <s></s> to strike through in Markdown style )

Do you think the before-commit hook should fire after prompting for the user checkin comment instead?

Yes, I think the provided comments are required before AND after the commitment. I suggest using the comments in a file, which can be provided to the hook script (per --command %M substitution). Then after the before-commit hook as run the same filename can be used for the comments which goes into the timeline. This way the hook gets the users comments but the hook script itself would be able to make adjustments or automated additions.

commit-msg

There was a not yet implemented hook type comment-msg foreseen. I think such a hook would make sense between the before-commit hook and the commitment itself; the last chance to get the automated additions of the before-commit hook styled and formatted for the timeline appearance - or replaced by whatsoever.

after-commit

I strongly recommend to add the fossil hook --type after-commit with the same meaning as the after-receive but without the network required sync/push/pull activity. - Difference between after-commit and after-receive on the far end: If the after-commit hook script fails with the wrong return code then the autosync step would not be initiated; the user's chance to do corrective work which finally gets sync'ed all together.

Are you (MBL) willing to become our official hook-stress-test contact person? :-)

I am proud of this question to me and will do my very best to support the beautiful tool fossil to become better and better for more and more use cases; but keep in mind that I am not a full-time programmer and my time for these tasks is limited. Having read the most recent post from (3) By John Rouillard (rouilj) on 2020-08-28 22:00:54 in reply to 2 I do not know if I am the right person or not. He has really good hints for the fossil hook system and made me think further. His experience with non-distributed systems is valuable input and should be seriously considered.

Some of these may not be possible in a distributed environment. The only choice may be to delay failure detection to the CI/CD step and then try to figure out how to notify the miscreant that they broke things.

On server-side the after-receive hook script could run fossil update into a local checkout stage area (let's call it a DMZ), do whatever corrective work can be done (or for example automated amalgamation) and then re-commit or -for CI/CD purposes only- commit into another repository for deployment with looping through the list of remote urls for fossil all sync. One fossil server --repolist instance could give access to both instances. This would probably imply the need for two local checkouts simultaneously; one of which would be _FOSSIL_ or .fslckout. To allow an additional parameter to use a checkout file of any name would enable such DMZ activities. Switching could be another solution. I already suggested in another post something like that (however, for a different use-case). See forumpost/disconnected local fossil status check (without having repository access): fossil freeze FILENAME for temporary close with the ability to give the frozen _fossil_ file another name and fossil unfreeze FILENAME to open such a frozen status. (The frozen file would remember how the checkout was opened before and on which branch. - As an extra for me the freezing step would also add and update file sizes and times of checkin/checkout of the checked out file artifacts for disconnected usage.)

Do I have too many use cases in mind or is something like this feasible with fossil-scm? Richard (drh), may I convince you now about the fossil freeze [FILENAME] and fossil unfreeze [FILENAME] commands? ;-)

Best regards MBL

The latest trunk check-in moves the before-commit hook until after the check-in comment has been collected, and it includes the check-in comment as part of the check-in information file that is provided to the hook.

I gave up for now with my tool chain ... will wait for the next deployment of the windows binaries. I ran out of time.

I succeeded in some steps but one last error I do not know how to solve:

tcc -g -Os -Wall -DFOSSIL_ENABLE_MINIZ -DFOSSIL_DYNAMIC_BUILD=1  -D__MINGW32__ -Dstrtoll=_strtoi64 -DFOSSIL_ENABLE_MINIZ -I. -I./src -I./bld  -o ./bld/winhttp.o -c ./bld/winhttp_.c
./src/winhttp.c:711: error: ';' expected (got "ssStatus")
gmake: *** [Makefile:2170: bld/winhttp.o] Error 1
D:/DownloadedFiles/Fossil-SCM/from-source $

In file ./src/winhttp.c at that lines you can find the following:

static SERVICE_STATUS ssStatus;
static SERVICE_STATUS_HANDLE sshStatusHandle;

I cannot find following declarations in any file or folder:

• SERVICE_STATUS
• SERVICE_STATUS_HANDLE

Where or how are they declared?

https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_status

You can get this by including <windows.h> per the documentation:

Header	winsvc.h (include Windows.h)

Thank you very much ... one step further ... but unfortunately still something more to search for to solve ... a longer list of undefined symbols