Git and Scmbug integration
Hello,
I've been working on adding Git support in Scmbug, a system that integrates software configuration management with bug-tracking. I've run across what seem to be limitations in the Git hooks mechanism (at least in version 1.5.1.3). In particular:
(1)
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
(2)
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments. The "update" trigger supplies a lot of information but that's only triggered when changes are published to a remote repository.
I could not find a way to extract this information from what I've read in:
http://www.kernel.org/pub/software/scm/git/docs/hooks.html
Are there plans to implement these hooks ? Or, could someone help me understand how to extract such information ?
Thanks,
Kristis
_______________________________________________
scmbug-users mailing list [email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
Kristis Makris, Tue, Nov 13, 2007 20:06:32 +0100:
Quoted 3 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
what for?
Quoted 5 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments.
HEAD?
Quoted 3 lines · Alex Riesen
Quoted 1 line
There's no hook that will trigger when a tag is applied.
what for?
To implement the synchronous verification checks provided by Scmbug:
http://www.mkgnu.net/?q=scmbug
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-23-0/manual/html-single/manual.html#VERIFICATION-CHECKS
In particular:
(1) Convention-based labeling
(2) The capability to freeze access to certain branches
http://bugzilla.mkgnu.net/show_bug.cgi?id=859
(3) Valid product-name verification
There are a lot more checks, as you can see from the manual, that are needed on a commit trigger, rather than just a tag trigger.
A lot of people find the integration provided by Scmbug useful and some (Jakub, back me up here) have requested support for Git.
Quoted 7 lines · Alex Riesen
Kristis Makris, Tue, Nov 13, 2007 20:06:32 +0100:
Quoted 3 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
what for?
Quoted 7 lines
Quoted 5 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments.
HEAD?
That wouldn't be particularly safe if you have a very quick succession of commits (say, via a rebase, or automated operations) because HEAD could be moved by the time the post-commit hook reads it.
Dave.
David Symonds, Wed, Nov 14, 2007 00:53:43 +0100:
Quoted 5 lines · Alex Riesen
Quoted 4 lines
Quoted 4 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
The commit trigger seems to be "post-commit" but it supplies no arguments.
HEAD?
That wouldn't be particularly safe if you have a very quick succession of commits (say, via a rebase, or automated operations) because HEAD could be moved by the time the post-commit hook reads it.
How's that? git-commit waits for its hooks.
Quoted 8 lines · Alex Riesen
David Symonds, Wed, Nov 14, 2007 00:53:43 +0100:
Quoted 7 lines · Alex Riesen
Quoted 6 lines
Quoted 5 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
HEAD?
That wouldn't be particularly safe if you have a very quick succession of commits (say, via a rebase, or automated operations) because HEAD could be moved by the time the post-commit hook reads it.
How's that? git-commit waits for its hooks.
Okay, so if it triggers an asynchronous process it just needs to be careful enough to pass whatever HEAD resolves to at the time. Cool.
Dave.
Quoted 8 lines · Kristis Makris
Hello,
I've been working on adding Git support in Scmbug, a system that integrates software configuration management with bug-tracking. I've run across what seem to be limitations in the Git hooks mechanism (at least in version 1.5.1.3). In particular:
Quoted 5 lines
(1)
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
I believe the 'update' hook is run when the tag is pushed.
Quoted 9 lines
(2)
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments. The "update" trigger supplies a lot of information but that's only triggered when changes are published to a remote repository.
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.
Dave.
Quoted 5 lines · David Symonds
Quoted 3 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
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 6 lines
Quoted 6 lines
(2)
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
Quoted 7 lines
Quoted 3 lines
The commit trigger seems to be "post-commit" but it supplies no arguments. The "update" trigger supplies a lot of information but that's only triggered when changes are published to a remote repository.
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=49011
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.
Quoted 6 lines · Kristis Makris
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.
I disagree somewhat here. In git, local commits are extremely lightweight, and as a developer I don't want anything remarkable to happen on those, even locally. It's pushing (which is actually publishing!) that makes those commits relevant.
Even if I have a local or distributed bugtracker, any purely local commit is "draft".
And this is regardless of centralised or distributed -- that's a matter of policy around the repo I'm pushing to. The distinction that matters is local vs published. Local commits get removed, rebased, redone, discarded a whole lot.
Quoted 2 lines
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.
I concur with the chorus that chants "HEAD"... try with git show HEAD for starters...
cheers,
martin
Quoted 9 lines · Kristis Makris
Quoted 5 lines · David Symonds
Quoted 3 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
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.
Unannotated tags don't make a proper new object, only a ref. If you stick to annotated tags, you'll get new objects added which, I think, should trigger the post-commit hook.
Quoted 4 lines
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.
If you have the new commit's SHA-1, it's very simple to get the parent commit's SHA-1 and do whatever you want. A complexity would be with handling merges, where a commit has multiple parents. If you have a commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>" to get a list of the files changed by <hash>.
Dave.
Quoted 6 lines · David Symonds
Quoted 5 lines · Kristis Makris
Quoted 4 lines · David Symonds
Quoted 3 lines
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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.
Unannotated tags don't make a proper new object, only a ref. If you stick to annotated tags, you'll get new objects added which, I think, should trigger the post-commit hook.
I just tried again tagging with both:
$ git tag TAG_NAME
$ git tag -a TAG_NAME
and I don't get the post-commit hook executed.
Perhaps I missed something ?
Quoted 10 lines
Quoted 4 lines
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.
If you have the new commit's SHA-1, it's very simple to get the parent commit's SHA-1 and do whatever you want. A complexity would be with handling merges, where a commit has multiple parents. If you have a commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>" to get a list of the files changed by <hash>.
This sounds great. If the post-commit hook could now provide the new commit SHA-1 hash than that should be what I need.
Can the new commit SHA-1 hash be added as a parameter to the post-commit hook please ?
Quoted 9 lines · Kristis Makris
I just tried again tagging with both:
$ git tag TAG_NAME$ git tag -a TAG_NAMEand I don't get the post-commit hook executed.
Perhaps I missed something ?
You didn't. You did not create any commit. No post-commit hook runs. There is no post-tag hook.
Quoted 2 lines
Can the new commit SHA-1 hash be added as a parameter to the post-commit hook please ?
Looking at "git-rev-parse HEAD" in your hook should be enough.
A message that is not in the archive (sent off-list or not yet received): 7vtznppr8m.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org
Quoted 12 lines · Junio C Hamano
Quoted 9 lines · Kristis Makris
I just tried again tagging with both:
$ git tag TAG_NAME$ git tag -a TAG_NAMEand I don't get the post-commit hook executed.
Perhaps I missed something ?
Quoted 7 lines
You didn't. You did not create any commit. No post-commit hook runs. There is no post-tag hook.
Quoted 2 lines
Can the new commit SHA-1 hash be added as a parameter to the post-commit hook please ?
Looking at "git-rev-parse HEAD" in your hook should be enough.
But ... which hook ? There is not post-tag hook!!
_______________________________________________
scmbug-users mailing list [email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
Quoted 6 lines · Kristis Makris
Quoted 3 lines
Unannotated tags don't make a proper new object, only a ref. If you stick to annotated tags, you'll get new objects added which, I think, should trigger the post-commit hook.
I just tried again tagging with both:
Quoted 7 lines
$ git tag TAG_NAME$ git tag -a TAG_NAMEand I don't get the post-commit hook executed.
Perhaps I missed something ?
Okay, I don't know about that. Someone else might want to weigh in on this.
Quoted 11 lines
Quoted 5 lines
If you have the new commit's SHA-1, it's very simple to get the parent commit's SHA-1 and do whatever you want. A complexity would be with handling merges, where a commit has multiple parents. If you have a commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>" to get a list of the files changed by <hash>.
This sounds great. If the post-commit hook could now provide the new commit SHA-1 hash than that should be what I need.
Can the new commit SHA-1 hash be added as a parameter to the post-commit hook please ?
Sure -- I've got a patch for it that I'll send shortly. It's using the existing shell git-commit, so might be suitable for maint; I haven't followed what's happened with the builtinification of git-commit.
Dave.
Quoted 3 lines · David Symonds
Sure -- I've got a patch for it that I'll send shortly. It's using the existing shell git-commit, so might be suitable for maint; I haven't followed what's happened with the builtinification of git-commit.
No, 'maint' won't get a feature enhancements.
Again, why isn't reading HEAD enough?
Quoted 7 lines · Junio C Hamano
Quoted 3 lines · David Symonds
Sure -- I've got a patch for it that I'll send shortly. It's using the existing shell git-commit, so might be suitable for maint; I haven't followed what's happened with the builtinification of git-commit.
No, 'maint' won't get a feature enhancements.
Fair enough.
Quoted 1 line
Again, why isn't reading HEAD enough?
Reading HEAD would be fine. I guess it just seems a sensible and more direct path to passing that information so that the hook has less to do. It seems quite a simple thing that would be very helpful to hook writers, with zero impact on everyone else.
Dave.
Quoted 4 lines · David Symonds
Reading HEAD would be fine. I guess it just seems a sensible and more direct path to passing that information so that the hook has less to do. It seems quite a simple thing that would be very helpful to hook writers, with zero impact on everyone else.
You cannot just say "The hook did not get any parameter, nobody would have cared, this does not regress."
Some anal people could have checked and checked "test $# = 0" at the beginning to make sure their hooks do not get broken by random interface changes on the git side. Now their carefully written script errors out as designed. Also some people seem to use different version of git on the same repository (e.g. NFS mounted across hosts that run different versions of git).
I would 80% agree with you if the post-comit hook interface were written in the way your patch does from day one. Unfortunately that is not the case.
The remaining 20%? If we _were_ to change the hook interface, I would also pass which branch the commit is added to, in addition to what commit it is.
Both are easily obtainable by reading HEAD (you need to read HEAD twice, though) but would be handy.