Karl Hasselström wrote:
On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:
Karl Hasselström wrote:
On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
Karl Hasselström wrote:
Also, if StGit is to set up hooks automatically (commit hooks,
pre-rebase hooks, whatever), it'd be nice to not have to worry
about overwriting any existing hooks the user might have. But
git currently allows only one hook script per hook, right?
Yes, but you can obviously call any number of scripts and
programs from within the hook that git executes.
That doesn't help here, however, since the user and not StGit
"owns" the "top-level" hook. StGit would have to rely on the user
having installed a specific kind of multiplexer as a hook script
(e.g. one that executes everything under .git/hooks/$hook.d/). Or
it would have to install it itself, and hope that moving any
existing hook to the subdirectory where the multiplexer looks for
hooks doesn't break anything. Both solutions are problematic.
The user-defined hook can be kept in the hooks directory too. It
just needs to be named in such a way that git will never have a hook
named like that. For that reason, I think it would be easiest to
just agree for the git core to never call any hooks prefixed with
"stgit" or some such. I think the odds for it happening by chance
are remote, to say the least.
You've lost me. :-/
Take the pre-commit hook as an example. git will call
".git/hooks/pre-commit" when interesting stuff happens. Now StGit
wants to install its pre-commit hook in an existing repository, and
finds that there already is a file called ".git/hooks/pre-commit".
What should it do?
Move the existing hook to ".git/hooks/stgit-moved.pre-commit". So
long as the hook doesn't care what its named (which would only matter
in the insane case where the repository has a single hook with a lot
of links going to it), this will work with relative paths that worked
earlier.
It could move ".git/hooks/pre-commit" to
".git/hooks/pre-commit.d/user_hook", install its own hook in
".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
".git/hooks/pre-commit". But that makes some assumptions, e.g. that
the user's hook can handle being moved, and that the user is fine with
this.
I don't see a good way around this other than having git mandate the
multiplexing scheme.
Multiplexing the execution of those hooks would be a very bad idea
indeed, but that's a different issue.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
