I'm stuck trying to configure a git-like pre-commit hook
(1) By anonymous on 2019-11-30 07:26:57 [link] [source]
I want a git-like pre-commit hook as specified in man githooks
Quote for reference:
pre-commit This hook is invoked by git commit, and can be bypassed with the --no-verify option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with a non-zero status from this script causes the git commit command to abort before creating a commit.
What have I done so far:
-
Recompiled fossil with tcl and th1 support as suggested here https://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki
My fossil buildscript has these now:
configure ...\ --with-th1-hooks \ --with-tcl=1 \ --with-tcl-private-stubs=1
- Enabled tcl and th1-hooks settings in my sandbox fossil repo by checking boxes via admin web interface in Admin -> Settings
-
Used https://fossil-users.fossil-scm.narkive.com/k181QuAG/hooks-in-fossil as reference and set up the th1 hook in Admin -> Settings -> th1-setup
It looks like this:
proc command_notify {} { if {$::cmd_name eq "commit"} { tclInvoke exec ./pre-commit & } }
-
Wrote the pre-commit script, its content is
#!/bin/bash
and made it executable.echo "this is a pre-commit hook"
Now, when I do fossil commit, I see something like this:
New_Version: 4508082730dd86173c71e960953b9cacd7fe89539791fcbe67ff6715f7564c7f this is a pre-commit hook
My assumption is that my bash hook gets executed after the commit actually happens, because, as specified here https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html it is run in background and "There is no connection between that program and the Tcl script, both can run on independently."
This is not what I want, so I've tried to modify the th1-setup script by removing the '&'. This way it doesn't seem to work at all, because I don't see the echoed line from my bash script anymore when I'm committing. Unfortunately, the same tcl doc page mentioned above states "NOTE: add information on how to wait for the program to finish?" so I'm stuck.
This leaves me with the following TODO list:
- Modify the th1-setup script so my pre-commit bash script hook gets executed in blocking mode rather than in background
- Process the return code of pre-commit script inside the th1-setup script
- If the return code is not 0, then abort the fossil commit
(2) By Stephan Beal (stephan) on 2019-11-30 07:51:00 in reply to 1 [link] [source]
This may be incorrect, but my understanding is that fossil commit hooks do not run until the artifact is already generated, at which point a hook has no possibility to cancel the commit. AFAIK (again, maybe incorrect), it's not possible to do a pre-commit hook which can abort the creation of the commit artifact. (That said, i'm finding no docs on the topic, and have never used hooks in fossil, so i'm going only from fallible memory of old discussions.)
(3) By anonymous on 2019-12-02 15:01:51 in reply to 2 [link] [source]
So what are my options then? Should I just write a shell script wrapper for the fossil binary, do all the pre-commit hook logic there and then just call fossil to perform the commit if everything is fine?
(4) By Stephan Beal (stephan) on 2019-12-02 15:13:33 in reply to 3 [link] [source]
That's about your only option, yes. The information fossil gives to hooks, namely artifact IDs, do not exist until the database has been updated, at which point it's too late to be able to veto the artifacts' creation. It's a ... dare i say it... checkin/egg problem.
(7) By Warren Young (wyetr) on 2020-05-05 14:19:23 in reply to 2 [link] [source]
fossil commit hooks do not run until the artifact is already generated, at which point a hook has no possibility to cancel the commit
My understanding is that Fossil TH1 commit hooks are built atop SQLite commit hooks, which means you're right, that it only runs after the artifact bits hit the disk.
However, that means it also runs before autosync, which suggests that if the hook rejects the commit, the artifact can surely be plucked from the DB using the purge
mechanism. Ugly but workable, no?
i'm finding no docs on the topic
The feature's document is marked as a draft and not linked into the combined index. I assume these are flip sides of the same coin.
(5) By anonymous on 2019-12-04 12:25:38 in reply to 1 [source]
You might want to take a look at the Fossil Wrapper project which might address your problem.
http://fossil.0branch.com/fsl/home
My understanding (which is limited!) of git pre commit hooks is that they were simply run prior to the actual commit and were blocking (a non zero return aborts the commit) and not dependant on values returned by the commit process - i.e. they are a 'convenience feature', for example, they can be used to parse and reformat line endings etc. I have used the fsl wrapper (linked above) to auto reformat KiCad files prior to committing them. I had previously tried using the pre-commit hooks but ran into similar problems to you. Sure the 'correct' way is not to produce defective artefacts in the first place but this wrapper can be used for lightweight reformatting or post processing.
(6) By anonymous on 2020-05-05 14:04:01 in reply to 5 [link] [source]
My understanding (which is limited!) of git pre commit hooks is that they were simply run prior to the actual commit and were blocking (a non zero return aborts the commit) and not dependant on values returned by the commit process - i.e. they are a 'convenience feature', for example, they can be used to parse and reformat line endings etc.
One popular use of git pre-commit hooks is to enforce commit message formatting, spell-check, even do code-linting for the to be checked-in files. With a review workflow (like gerrit), the review tags are also inserted at pre-commit.