The idea is stemmed from discussions/problems with using freeze/thaw hooks, and in particular line of thinking in the comment on specify_freeze47thaw_scripts_relative_to_topdir. ATM git-annex does analysis of either repository needs any special handling (adjusted branch, pidlock, etc) during annex init and otherwise does not bother. It would make sense to make it possible for a user to also be able similarly to
- test e.g. if custom freeze/thaw are needed (before even git annex decides to switch to adjusted branches mode) and setup that repo accordingly for git-annex to proceed without flipping out into adjusted branch mode
- may be improved/custom pidlock detection (on one of my servers I remember needing to just hardcode in ~/.gitconfig to use pidlock although that was relevant only for some paths).
- similarly do some other testing which could allow or disallow some git-annex decision such as e.g. use of adjusted unlocked branch
I even wonder if there could be some easy way to setup overall hook for
git-annexinvocation within a repo (hence within.git/of a repo) to e.g. safe-guard invocations of git-annex and prevent use within container environments (we often run into various problems). So smells to me like developing some kind of.git/annex/hooks/support analog to.git/hooks. Then whatever globalannex inithook would setup for a repo within its.git/annex/hookswould be in effect for subsequentannexinvocations within containers or natively.Other desired use-cases could be to prevent invocation of git-annex with known critical for that deployment defects/absent features (e.g. absent support of freeze/thaw scripts or some other recent feature).
Seems like a reasonable idea to have a hook that runs before
git-annex initdoes any of its probing or configuration.As for generalizing to a hook that is run before each git-annex command, putting it in .git/hooks seems like it could cause a fair bit of extra work probing if the hook(s) exist, especially in cases where git-annex runs git which might run git-annex again repeatedly.
There could be a generalized hook config, eg
git config annex.pre-hook my-hookcould makegit-annex initrunmy-hook git-annex initand same for other git-annex commands.It sounds like you would want a failure of such a hook to prevent the git-annex command from running. Is that right?
Worth bearing in mind that if such a hook output to stdout, or read from stdin, or for that matter was interactive on /dev/tty, it could badly mess up things that use git-annex as plumbing. Including git, in the case of the smudge filter.
I feel that having such a generic gateway hook would be
.git/hooksoperate (separate scripts for different operations)If someone wanted such one, they could create a "symlink" driven generic hook which would have resolved its action upon
$0name as some tools etc do.I really feel that having
annex.pre-{command}-hookset of configurations would be cleaner.I think so... and I think that's how git hooks perform? (less git-annex is special the better)
Yes, a single pre-hook that gets run by every command would not be great for performance. Especially when git is eg sometimes running
git-annex smudgerepeatedly.You earlier spoke of "overall hook for git-annex invocation within a repo". Did you just mean a hook that runs before initialization, and not a hook that runs before every git-annex command?
I feel more comfortable with adding a pre-init hook than pre-everything hooks. For one thing, it makes sense for that hook to prevent initialization if there is a reason to want to avoid that. It makes a lot less sense for a
pre-smudgehook to prevent that bit of git-annex plumbing from working, which can have very different effects depending on what git is doing, or for apre-findhook to output something to stdout.Note that the
.noannexfile that prevents init has some overlap with a pre-init hook that exits nonzero. I guess the .noannex file has the benefit of working in every clone of a repository without additional configuration.Implemented .git/hooks/pre-init-annex (and alternatively git config annex.pre-init-command)
Note that this is also run before automatic initialization.