On Wed, 2007-11-14 at 10:00 +1100, David Symonds wrote:
quoted text
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=3D991
> >
> > There's no hook that will trigger when a tag is applied.
>=20
> I believe the 'update' hook is run when the tag is pushed.

Even if that is true, there no hook that will trigger when a local tag
is applied.

quoted text
> > (2)
> >
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=3D992
> >
> > Git does not offer metadata describing a change on the commit trigger
> >
> > The commit trigger seems to be "post-commit" but it supplies no argumen=
ts. The
quoted text
> > "update" trigger supplies a lot of information but that's only triggere=
d when
quoted text
> > changes are published to a remote repository.
>=20
> Isn't this some kind of centralised bug-tracking system anyway? It
> would be nice, I see, for the 'commit' hook to take, say, the commit
> SHA-1 hash as a parameter.

It isn't a centralized bug-tracking system necessarily. Because
different developers may used different, custom bug-tracking systems,
with custom hooks in their own local Git repositories that integrate
with only their own bug-tracking systems. And perhaps we can add the
support in the Scmbug Git frontend to integrate with a centralized
bug-tracker only on push operations if desired.

But we can't explore any of these issues, discussed in the thread below
too, unless we can extract what's needed from the hooks.

http://thread.gmane.org/gmane.comp.version-control.git/48981/focus=3D49011


I'd like the commit hook to provide enough information to be able to
tell which files were modified and their respective old/new version (or
perhaps their old/new SHA-1 hash). If the new SHA-1 hash can be used to
extract all that, that's ok with me. But right now there's nothing.