mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2025-01-09 14:23:51 -04:00
parent 726f801946
commit de62975065
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 62 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

27
doc/todo/Support___40__globally_configured__41_____34__annex_init__34___hooks/comment_2_0015660a3ede2c3181f960b9c2bac81c._comment Normal file
View file

@ -0,0 +1,27 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2025-01-09T17:38:25Z"
content="""
Seems like a reasonable idea to have a hook that runs before `git-annex
init` does 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-hook` could make `git-annex init` run `my-hook git-annex init`
and 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.
(Should this todo be tagged repronim btw?)
"""]]

35
doc/todo/specify_freeze__47__thaw_scripts_relative_to_topdir/comment_4_5a510abfe992a1aa4d7e2edcd9f6844b._comment Normal file
View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2025-01-09T17:57:05Z"
content="""
I can see how it would be simpler for you to just be able to have those
hooks in .git/hooks/ along with the rest of the repository.
I don't think that a special casing of "./" is a good idea, that would be
pretty confusing and for all I know some user might really want git-annex
to run a hook in the current directory of their git repository.
I am meh on "%dotgit", for one thing in a bare repository it's not `.git`.
What if git-annex just added the git hooks directory to the end of PATH
when running configured `annex.*-command`s? Then you could: `git config
annex.thawcontent-command annex-thawcontent` and put your script in
.git/hooks/annex-thawcontent
This nicely avoids git-annex doing any extra work in general to check if
.git/hooks/ exist.
The reason I think it would need to be at the end of PATH rather than the
front is that there are some git hooks with names like "update" and "applypatch"
that I can imagine might have the same names as a user's own programs
in their PATH. For example, if `annex.commitmessage-command=foo` and the
script foo runs "update", the user would be surprised if that ran the git
hook rather than their `~/bin/update`.
On the other hand, when configuring a `annex.*-command`, it does not seem
likely that the user would set it to "update" or any of the other names
of git hooks. Especially if they didn't have an "update" in PATH.
So using the git hook directory for this, rather than some
other special directory under .git seems ok.
"""]]