Theodore Tso [off-list ref] writes:
On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:
quoted
So: ideally, what /I/ would like is that git distributes the script in a
standard location like /usr/share/doc/git/contrib/post-receive-emailer
with the execute bit already set; that can be easily linked to or
called from the actual post-receive hook.
I wonder if this is a good idea to do for all or most of the template
scripts, so that they can get automatically updated when git is
updated, instead of having the problem we had before where the hook
script got updated to match changes in git, but ancient repositories
would still have the old script.
I do agree that dealing with ancient scripts that casually used
implementation details that later versions broke is a problem.
But the recent updates to the mail-hook are backward compatible
only in the sense that as long as the user configures it, the
new script can mimic old version's behaviour (in other words, it
was not backward compatible at all). I think forcing updates to
the hooks automatically is worse. I'd rather keep hooks private
to repository owner's concern.
While I think it would be great to have a central clearinghouse
for people to share and enjoy useful hook collections for
various workflows and use cases, I do not necessarily think
inside git.git project itself is the best place to do so.
On Saturday 2007, March 24, Junio C Hamano wrote:
But the recent updates to the mail-hook are backward compatible
only in the sense that as long as the user configures it, the
new script can mimic old version's behaviour (in other words, it
was not backward compatible at all). I think forcing updates to
the hooks automatically is worse. I'd rather keep hooks private
to repository owner's concern.
But the user is still perfectly fine to /copy/ the script into
individual repositories; but for those who don't care and just
want "the latest and greatest" from whatever git supplies a link to the
sample hook seems like a good solution. I'm certainly not suggesting
updating the ones in people's repositories automatically; what I'm
suggesting is this:
ln -s \
/usr/doc/git/contrib/post-receive-email
/var/lib/git/project.git/hooks/post-receive
Or perhaps have the template post-receive hook simply contain
. /usr/doc/git/contrib/post-receive-email
With the above in place when a user upgrades git with their package
manager, and they have enabled the default hook script (which simply
calls the one stored in a known location), they get the upgrade without
having to think.
While I think it would be great to have a central clearinghouse
for people to share and enjoy useful hook collections for
various workflows and use cases, I do not necessarily think
I agree - filling the place with every hook script that turns up is
obviously not sensible. However, this is not a hook collection; nor
are their "people", there is just me. Shawn asked if I'd convert the
existing update hook to post-receive, that's what I did. Show me these
other "hook collections" that are desparately trying to get this
apparently coveted position...
inside git.git project itself is the best place to do so.
Erm, where is the right place then?
I think that git should supply in git.git a default set that do
typically wanted things (things like the perfect patch pre-commit hook,
the no-unannotated-tags update hook, and of course the email sending
hook) that can be enabled with a simple chmod a+x hooks/somescript.
All I was doing was supplying a script to fill the post-receive slot.
That all sounds a lot more toys-out-of-pram than I intend; in the end,
I'm only trying to fix the bugs that are in old update-hook.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
On Sat, Mar 24, 2007 at 03:41:30AM -0700, Junio C Hamano wrote:
While I think it would be great to have a central clearinghouse
for people to share and enjoy useful hook collections for
various workflows and use cases, I do not necessarily think
inside git.git project itself is the best place to do so.
What are your concernswith having a set of useful hook collections in
contrib/hooks, which get installed in /usr/share/git/hooks, or some
such? The nice of doing this is that various distro packages will
have the hooks installed in standardized places, which means that it
becomes easier for people distribute receipes on how to enable various
advanced bits of functionality by using 'ln -s /usr/share/git/hooks/FOO
.git/hooks/BAR', and it's standardized across distributions.
- Ted