From: Marc Weber <marco-oweber@gmx.de>
To: git@vger.kernel.org
Subject: What about allowing multiple hooks?
Date: Fri, 21 Nov 2008 14:38:28 +0100 [thread overview]
Message-ID: <20081121133828.GB5912@gmx.de> (raw)
Use case:
I've been reading parts of the topGit code. And it does make for it to
add its own checks. However having to change the existing scripts
insterting a call to the tg hooks isn't the best way.
Why? one is using #/bin/sh the next is using #/bin/ruby maybe..
So what about allowing (or even enforcing) ths directory layout?
.git/hooks/pre-commit/hook1.sh
.git/hooks/pre-commit/hook2.sh
.git/hooks/pre-commit/topGitcheck.sh
instead of
.git/hooks/pre-commit # <- the one and only pre-commit hook
so that all can be run in squence?
This way you can keep the original git sample files and update them
while adding you very own checks more easily.
But maybe this isn't the best choice either and the way to go is
.git/hooks/list-of-hook-directories # eg containing ".git/hooks/samples\n.git/hooks/topgit" ?
.git/hooks/sample/<all the sample hook files>
.git/hooks/topgit/pro-commit
?
Then you can actually link in your own personal check script directories
easily *and* you can add them to the repository eg by using
comitted-repo-hooks instead of .git/hooks
?
This way you could provide different hook directories for different
platforms and all you have to do is enabling them by adding the path to
.git/list-of-hook-directories ?
I guess the second approach of defining kind of overlays is better
because it doesn't interfer with the existiing scheme?
Maybe it should be implemented as git config option instead of a file
containing the list of directories?
The hook direcotry list apporach is better because you've more control
about order of execution..
Thoughts?
Marc Weber
next reply other threads:[~2008-11-21 13:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 13:38 Marc Weber [this message]
2008-11-21 13:55 ` What about allowing multiple hooks? martin f krafft
2008-11-21 14:56 ` Rogan Dawes
2009-01-03 23:32 ` Alexander Potashev
2009-01-04 10:01 ` Junio C Hamano
2009-01-21 20:35 ` Anders Waldenborg
2009-01-21 21:10 ` Johannes Schindelin
2009-01-21 21:30 ` Anders Waldenborg
2009-01-21 21:50 ` Johannes Schindelin
2009-01-22 9:57 ` Anders Waldenborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081121133828.GB5912@gmx.de \
--to=marco-oweber@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).