{"thread":{"id":"15796","subject":"Git and tagging hook","startedAt":"2008-10-06T04:45:32Z","lastAt":"2008-10-17T07:04:52Z","messageCount":15,"participants":["Kristis Makris","Andreas Ericsson","Jakub Narebski","Jan Hudec","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"92384","messageId":"1223268332.4072.7.camel@localhost","threadId":"15796","inReplyTo":null,"subject":"Git and tagging hook","fromName":"Kristis Makris","fromEmail":"kristis.makris-ttjs1oqo2yy@public.gmane.org","sentAt":"2008-10-06T04:45:32Z","receivedAt":"2008-10-06T04:45:32Z","isPatch":false,"sender":{"key":"kristis.makris-ttjs1oqo2yy@public.gmane.org","avatar":null},"body":"Hello,\n\nIt seems that Git (at least v1.5.6) does not offer hooks on tag creation\n(a pre-tag and a post-tag hook). I need such a hook for integrating tag\nactivities with an issue-tracker. Is it possible to add this hook ?\n\nI had asked about this in the past, but did not receive a response.\n\nhttp://bugzilla.mkgnu.net/show_bug.cgi?id=991\n\nThanks,\nKristis\n\n\n_______________________________________________\nscmbug-users mailing list\nscmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org\nhttp://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users\n"},{"id":"92393","messageId":"48E9BB72.2080008@op5.se","threadId":"15796","inReplyTo":"1223268332.4072.7.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-06T07:17:06Z","receivedAt":"2008-10-06T07:17:06Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kristis Makris wrote:\n> Hello,\n> \n> It seems that Git (at least v1.5.6) does not offer hooks on tag creation\n> (a pre-tag and a post-tag hook). I need such a hook for integrating tag\n> activities with an issue-tracker. Is it possible to add this hook ?\n> \n\nWhat you want is probably the post-receive or 'update' hooks on whatever\nrepository you consider your public watering hole for your project.\nIntegrating with an issue-tracker from the developers machine would be\nutterly stupid, as it would prevent tagging from happening while not\nconnected.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"92394","messageId":"48E9BC54.5070609@op5.se","threadId":"15796","inReplyTo":"1223268332.4072.7.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-06T07:20:52Z","receivedAt":"2008-10-06T07:20:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Next time, don't include a members-only list in the CC, please. The\nusual action when replying to an email on git@vger is to \"Reply All\",\nwhich doesn't play nicely with such lists and will render one list\narchive incomplete (since people will inevitably cull that other\nlist from their CC's after having sent to it once).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"92551","messageId":"1223399613.20250.1.camel@localhost","threadId":"15796","inReplyTo":"48E9BB72.2080008@op5.se","subject":"Re: Git and tagging hook","fromName":"Kristis Makris","fromEmail":"kristis.makris@asu.edu","sentAt":"2008-10-07T17:13:33Z","receivedAt":"2008-10-07T17:13:33Z","isPatch":false,"sender":{"key":"kristis.makris@asu.edu","avatar":null},"body":"But the post-receive is NOT executed when I apply a tag.\n\nI want the integration when I apply the tag to a local repository, NOT\nonly when I push/pull.\n\nOn Mon, 2008-10-06 at 09:17 +0200, Andreas Ericsson wrote:\n> Kristis Makris wrote:\n> > Hello,\n> > \n> > It seems that Git (at least v1.5.6) does not offer hooks on tag creation\n> > (a pre-tag and a post-tag hook). I need such a hook for integrating tag\n> > activities with an issue-tracker. Is it possible to add this hook ?\n> > \n> \n> What you want is probably the post-receive or 'update' hooks on whatever\n> repository you consider your public watering hole for your project.\n> Integrating with an issue-tracker from the developers machine would be\n> utterly stupid, as it would prevent tagging from happening while not\n> connected.\n> \n"},{"id":"92552","messageId":"gcg67d$4o2$1@ger.gmane.org","threadId":"15796","inReplyTo":"1223399613.20250.1.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-07T17:28:13Z","receivedAt":"2008-10-07T17:28:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kristis Makris wrote:\n\n> But the post-receive is NOT executed when I apply a tag.\n> \n> I want the integration when I apply the tag to a local repository, NOT\n> only when I push/pull.\n\nIf you are talking about taging locally, you can simply make an alias\nor do something after tagging. Search archives for description when\nit is worth to add a hook, and when it is not.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"92553","messageId":"1223400602.20250.2.camel@localhost","threadId":"15796","inReplyTo":"48E9BC54.5070609@op5.se","subject":"Re: Git and tagging hook","fromName":"Kristis Makris","fromEmail":"kristis.makris@asu.edu","sentAt":"2008-10-07T17:30:02Z","receivedAt":"2008-10-07T17:30:02Z","isPatch":false,"sender":{"key":"kristis.makris@asu.edu","avatar":null},"body":"On Mon, 2008-10-06 at 09:20 +0200, Andreas Ericsson wrote:\n> Next time, don't include a members-only list in the CC, please. The\n> usual action when replying to an email on git@vger is to \"Reply All\",\n> which doesn't play nicely with such lists and will render one list\n> archive incomplete (since people will inevitably cull that other\n> list from their CC's after having sent to it once).\n\nWhy would they cull that other list, if the usual action is to \"Reply\nAll\" ?\n"},{"id":"92580","messageId":"48EC4F5E.104@op5.se","threadId":"15796","inReplyTo":"1223400602.20250.2.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-08T06:12:46Z","receivedAt":"2008-10-08T06:12:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kristis Makris wrote:\n> On Mon, 2008-10-06 at 09:20 +0200, Andreas Ericsson wrote:\n>> Next time, don't include a members-only list in the CC, please. The\n>> usual action when replying to an email on git@vger is to \"Reply All\",\n>> which doesn't play nicely with such lists and will render one list\n>> archive incomplete (since people will inevitably cull that other\n>> list from their CC's after having sent to it once).\n> \n> Why would they cull that other list, if the usual action is to \"Reply\n> All\" ?\n\nBecause it's a members-only list. Like me, I'm sure many will get\nannoyed enough to remember to remove it for further postings on the\nsubject. Those nonsensical \"awaiting moderator approval\" emails are\nirritating noise, and since they're \"To: me\" and get a low spamrank\nthey go straight to the high-priority folder. Many others on this\nlist use similar filters as it's a neat way of dealing with several\nhigh-volume mailing lists sanely.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"92624","messageId":"1223484445.4055.8.camel@localhost","threadId":"15796","inReplyTo":"gcg67d$4o2$1@ger.gmane.org","subject":"Re: Git and tagging hook","fromName":"Kristis Makris","fromEmail":"kristis.makris-ttjs1oqo2yy@public.gmane.org","sentAt":"2008-10-08T16:47:25Z","receivedAt":"2008-10-08T16:47:25Z","isPatch":false,"sender":{"key":"kristis.makris-ttjs1oqo2yy@public.gmane.org","avatar":null},"body":"On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:\n> Kristis Makris wrote:\n> \n> > But the post-receive is NOT executed when I apply a tag.\n> > \n> > I want the integration when I apply the tag to a local repository, NOT\n> > only when I push/pull.\n> \n> If you are talking about taging locally, you can simply make an alias\n> or do something after tagging. Search archives for description when\n> it is worth to add a hook, and when it is not.\n\nI am looking for a guarantee that is better than casually saying\n\"simply\". I will be providing the integration work to users that may not\nbe as comfortable with making aliases. \n\nI still don't see why a hook on local tagging is not available. Is it\npossible to add support in Git for such a hook ? Both pre-tag and\npost-tag.\n\n\n_______________________________________________\nscmbug-users mailing list\nscmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org\nhttp://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users\n"},{"id":"92625","messageId":"48ECF072.3000506@op5.se","threadId":"15796","inReplyTo":"1223484445.4055.8.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-08T17:40:02Z","receivedAt":"2008-10-08T17:40:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kristis Makris wrote:\n> On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:\n>> Kristis Makris wrote:\n>>\n>>> But the post-receive is NOT executed when I apply a tag.\n>>>\n>>> I want the integration when I apply the tag to a local repository, NOT\n>>> only when I push/pull.\n>> If you are talking about taging locally, you can simply make an alias\n>> or do something after tagging. Search archives for description when\n>> it is worth to add a hook, and when it is not.\n> \n> I am looking for a guarantee that is better than casually saying\n> \"simply\". I will be providing the integration work to users that may not\n> be as comfortable with making aliases. \n> \n> I still don't see why a hook on local tagging is not available. Is it\n> possible to add support in Git for such a hook ? Both pre-tag and\n> post-tag.\n\nBecause noone's ever needed one before. If aliases can't do what you\nwant, write a patch to support it and hope Junio accepts it. It's really\nquite straight-forward. Make sure you read Documentation/SubmittingPatches\nbefore you send it.\n\nNote though that use of tags on the developer's side will still be up\nto the developer and not something you can force through other means\nthan policy or convention.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"93022","messageId":"20081014172227.GB6931@efreet.light.src","threadId":"15796","inReplyTo":"48ECF072.3000506@op5.se","subject":"Re: Git and tagging hook","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-10-14T17:22:27Z","receivedAt":"2008-10-14T17:22:27Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Oct 08, 2008 at 19:40:02 +0200, Andreas Ericsson wrote:\n> Kristis Makris wrote:\n>> On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:\n>>> Kristis Makris wrote:\n>>>> I want the integration when I apply the tag to a local repository, NOT\n>>>> only when I push/pull.\n\nCare to explain why that would ever be useful? It's local, which means that:\n - the user can take it back without a trace it ever happened (git tag -d or\n even git update-ref -d) and\n - noone except the user will see it anyway, so it's not like they should\n care either.\n\nBesides, you don't need git tag to create a tag in git, so the hook wouldn't\nreally be guaranteed anyway (I mean, just like the commit hook is not -- you\ncan still commit by calling write-tree, commit-tree and update-ref and avoid\nthe hook).\n\n>>> If you are talking about taging locally, you can simply make an alias\n>>> or do something after tagging. Search archives for description when\n>>> it is worth to add a hook, and when it is not.\n>>\n>> I am looking for a guarantee that is better than casually saying\n>> \"simply\". I will be providing the integration work to users that may not\n>> be as comfortable with making aliases. \n>>\n>> I still don't see why a hook on local tagging is not available. Is it\n>> possible to add support in Git for such a hook ? Both pre-tag and\n>> post-tag.\n>\n> Because noone's ever needed one before. If aliases can't do what you\n> want, write a patch to support it and hope Junio accepts it. It's really\n> quite straight-forward. Make sure you read Documentation/SubmittingPatches\n> before you send it.\n>\n> Note though that use of tags on the developer's side will still be up\n> to the developer and not something you can force through other means\n> than policy or convention.\n\nBeing possible was never a reason to add features to git and the less it was\na reason to add hooks. And there does not seem to be a use-case that would\nclearly benefit from having such hooks, or at least none was shown on the\nlist so far.\n\nFor integration with issue tracker, the local tag is neither final, nor\nuseful to anybody except the user who did it until it hits the central\nrepository. And working on the central repository directly does not seem like\na good idea either.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"93024","messageId":"1224007401.4073.40.camel@localhost","threadId":"15796","inReplyTo":"20081014172227.GB6931-hYs7FtC5zV+YSD4dQj0czg@public.gmane.org","subject":"Re: Git and tagging hook","fromName":"Kristis Makris","fromEmail":"kristis.makris-ttjs1oqo2yy@public.gmane.org","sentAt":"2008-10-14T18:03:21Z","receivedAt":"2008-10-14T18:03:21Z","isPatch":false,"sender":{"key":"kristis.makris-ttjs1oqo2yy@public.gmane.org","avatar":null},"body":"Jan, thanks for trying to clarify this for me.\n\nI am working on adding integration support of Git with bug-trackers,\nusing Scmbug. There may be an argument here towards/against distributed\nbug-trackers when it comes to Git.\n\nMaybe there are things here I don't fully understand yet.\n\nOn Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:\n> >>> Kristis Makris wrote:\n> >>>> I want the integration when I apply the tag to a local repository, NOT\n> >>>> only when I push/pull.\n> \n> Care to explain why that would ever be useful? It's local, which means that:\n> - the user can take it back without a trace it ever happened (git tag -d or\n> even git update-ref -d) and\n> - noone except the user will see it anyway, so it's not like they should\n> care either.\n\nI have two use cases:\n\n(1) A developer maintains besides his local copy a local bug-tracking\nsystem in which he tracks his changes. We would like to apply various\nverification policies when he commits or tags. For example, for tagging\nwe wants to ensure that he tags giving consistent labels to his\nintermediate builds. e.g. as in:\n\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING\n\nOr he may want to have Git force him to also supply a log message along\nwith a tag, so that he can remember later more accurately why a tag was\ncreated and what it really captures. Even if Git (or other SCM systems)\ndon't natively support log messages on tags. Scmbug plans to implement\nthis.\n\nhttp://bugzilla.mkgnu.net/show_bug.cgi?id=219\n\n\n(2) I would like to apply various verification policies when work from a\nlocal repository is finally merged with the central repository. I assume\nthere can/will be a central repository, and there is one \"software\nproduct\" that is being released somewhere among the many copies.\n\nWhen its time to merge local changes to a central repository, the\nverification policies may deem that changes are not acceptable to be\nmerged with the mainline. e.g. because log messages are too short,\ncommits during the merge are issued against bugs in \"a central\"\nbugtracker that are either closed, assigned to someone else, or just\nplain wrong bug-numbers that belong to other products:\n\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME\n\n(I'm not very clear whether this is how Git works)\n\nDoes someone get to write-up a brand new log comment during the merge\nand the merge totally disregards older log comments ? My understanding\nis that log comments on the local copy are preserved (and will need to\nbe mapped to bug-numbers in the central bug-tracker. \n\nThus the local verification policies may need to have already been\nconfigured to comply with future verification policies of the central\nrepository. Else (perhaps considerable) mappings/adjustments will be\nneeded during the push to the central copy.\n\n> Besides, you don't need git tag to create a tag in git, so the hook wouldn't\n> really be guaranteed anyway (I mean, just like the commit hook is not -- you\n> can still commit by calling write-tree, commit-tree and update-ref and avoid\n> the hook).\n\nI'm assuming someone who follows the recommended avenue of using Git\nwants the advantages of hooks. I certainly can't force people that\nbypass hooks to use them.\n\n> For integration with issue tracker, the local tag is neither final, nor\n> useful to anybody except the user who did it until it hits the central\n> repository. And working on the central repository directly does not seem like\n> a good idea either.\n\nThe local tag is useful to the local user and his local bug-tracker. He\ncan have tag operations intercepted so that the tag names show up as\nversions in his bug-tracker. In this way he can keep track of which bugs\nstill exist or have recently been introduced/discovered to his local\ncopy, before he decides to publish his polished, final version:\n\nhttp://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS\n\nAnd his \"local bug-tracker\" may be reachable on the web and useful by\nothers that take a peek at the users progress (even fetching it with\nGit).\n\n\n\n_______________________________________________\nscmbug-users mailing list\nscmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org\nhttp://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users\n"},{"id":"93029","messageId":"48F505BE.8040407@op5.se","threadId":"15796","inReplyTo":"1224007401.4073.40.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-14T20:49:02Z","receivedAt":"2008-10-14T20:49:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kristis Makris wrote:\n> Jan, thanks for trying to clarify this for me.\n> \n> I am working on adding integration support of Git with bug-trackers,\n> using Scmbug. There may be an argument here towards/against distributed\n> bug-trackers when it comes to Git.\n> \n> Maybe there are things here I don't fully understand yet.\n> \n> On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:\n>>>>> Kristis Makris wrote:\n>>>>>> I want the integration when I apply the tag to a local repository, NOT\n>>>>>> only when I push/pull.\n>> Care to explain why that would ever be useful? It's local, which means that:\n>> - the user can take it back without a trace it ever happened (git tag -d or\n>> even git update-ref -d) and\n>> - noone except the user will see it anyway, so it's not like they should\n>> care either.\n> \n> I have two use cases:\n> \n> (1) A developer maintains besides his local copy a local bug-tracking\n> system in which he tracks his changes. We would like to apply various\n> verification policies when he commits or tags. For example, for tagging\n> we wants to ensure that he tags giving consistent labels to his\n> intermediate builds. e.g. as in:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING\n> \n\nI'm guessing releases will be cut from some sort of central or official\nrepository anyway, so I fail to see why tags would need to be verified\nat create-time rather than at push-time. It's sometimes useful to create\ntags for ones own personal use, and commit messages that are no more than\n\"wip\", without signoff or anything. This needs to be implemented at the\nreceiving end. Not at each developers end.\n\n> Or he may want to have Git force him to also supply a log message along\n> with a tag, so that he can remember later more accurately why a tag was\n> created and what it really captures. Even if Git (or other SCM systems)\n> don't natively support log messages on tags. Scmbug plans to implement\n> this.\n> \n> http://bugzilla.mkgnu.net/show_bug.cgi?id=219\n> \n\ngit supports optional log-messages on tags. There are two different kinds\nof tags in git; \"annotated\" (with logmessage) and \"lightweight\" (without\nlogmessage). It's up to each user which sort of tag to create. Using the\nexample update hook, lightweight tags are by default not allowed to be\npushed to a repository.\n\n> \n> (2) I would like to apply various verification policies when work from a\n> local repository is finally merged with the central repository. I assume\n> there can/will be a central repository, and there is one \"software\n> product\" that is being released somewhere among the many copies.\n> \n\nMerges happen in the local repository. When a merge is pushed to the\n\"release\" repo, you can analyze the merges and all commits that the sender\nis trying to push.\n\n> When its time to merge local changes to a central repository, the\n> verification policies may deem that changes are not acceptable to be\n> merged with the mainline. e.g. because log messages are too short,\n> commits during the merge are issued against bugs in \"a central\"\n> bugtracker that are either closed, assigned to someone else, or just\n> plain wrong bug-numbers that belong to other products:\n> \n\nThat sort of work belongs in the update hook then. Cautious users, or\nrelease engineers, might want to enable pre-merge hooks and whatnot.\n\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME\n> \n> (I'm not very clear whether this is how Git works)\n> \n> Does someone get to write-up a brand new log comment during the merge\n> and the merge totally disregards older log comments ? My understanding\n> is that log comments on the local copy are preserved (and will need to\n> be mapped to bug-numbers in the central bug-tracker. \n> \n\nTry and find out. It would have been faster than writing that paragraph ;-)\n\n> Thus the local verification policies may need to have already been\n> configured to comply with future verification policies of the central\n> repository. Else (perhaps considerable) mappings/adjustments will be\n> needed during the push to the central copy.\n> \n>> Besides, you don't need git tag to create a tag in git, so the hook wouldn't\n>> really be guaranteed anyway (I mean, just like the commit hook is not -- you\n>> can still commit by calling write-tree, commit-tree and update-ref and avoid\n>> the hook).\n> \n> I'm assuming someone who follows the recommended avenue of using Git\n> wants the advantages of hooks. I certainly can't force people that\n> bypass hooks to use them.\n> \n\nHooks can also be disabled, and they aren't enabled by default. They're also\nnot cloned along with a repository (that would be stupid, as I most certainly\ndon't want the email-on-commit hooks we're using at work), so installing\nsaid hooks would still be a manual job done by each developer that wishes to\ncomply with the policy you're outlining. I have a hard time seeing how that\ncan benefit the open community.\n\n>> For integration with issue tracker, the local tag is neither final, nor\n>> useful to anybody except the user who did it until it hits the central\n>> repository. And working on the central repository directly does not seem like\n>> a good idea either.\n> \n> The local tag is useful to the local user and his local bug-tracker. He\n> can have tag operations intercepted so that the tag names show up as\n> versions in his bug-tracker. In this way he can keep track of which bugs\n> still exist or have recently been introduced/discovered to his local\n> copy, before he decides to publish his polished, final version:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS\n> \n> And his \"local bug-tracker\" may be reachable on the web and useful by\n> others that take a peek at the users progress (even fetching it with\n> Git).\n> \n\nRelying on hooks on the developer side is fragile and *will* break.\nIt will break often, and it will break badly. Any sort of\n\"this-commit-is-releasable\" verification simply *has* to be done in\nthe release repository. Otherwise you'll be limiting how devs can\nuse the scm while gaining absolutely nothing (since it has to be\ndone in the release repo too for those times when the dev forgot\nto enable hook X in a newly cloned repository).\n\nI still haven't figured out what the over-all plan is, so my\nadvice and warnings may be counter-productive at worst. However,\nhttp://files.mkgnu.net/files/scmbug/doc/latest_manual/html-multi/x113.html\njust doesn't make sense to me. It's invalidated by clear and\nconcise commit messages (which aren't always there, but education\nis nine times out of ten better than enforcement; It's better\nto understand *why* 6x7 = 42 rather than just knowing that it's\nso).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"93032","messageId":"alpine.LNX.1.00.0810141708450.19665@iabervon.org","threadId":"15796","inReplyTo":"1224007401.4073.40.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-10-14T21:33:37Z","receivedAt":"2008-10-14T21:33:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 14 Oct 2008, Kristis Makris wrote:\n\n> Jan, thanks for trying to clarify this for me.\n> \n> I am working on adding integration support of Git with bug-trackers,\n> using Scmbug. There may be an argument here towards/against distributed\n> bug-trackers when it comes to Git.\n> \n> Maybe there are things here I don't fully understand yet.\n> \n> On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:\n> > >>> Kristis Makris wrote:\n> > >>>> I want the integration when I apply the tag to a local repository, NOT\n> > >>>> only when I push/pull.\n> > \n> > Care to explain why that would ever be useful? It's local, which means that:\n> > - the user can take it back without a trace it ever happened (git tag -d or\n> > even git update-ref -d) and\n> > - noone except the user will see it anyway, so it's not like they should\n> > care either.\n> \n> I have two use cases:\n> \n> (1) A developer maintains besides his local copy a local bug-tracking\n> system in which he tracks his changes. We would like to apply various\n> verification policies when he commits or tags. For example, for tagging\n> we wants to ensure that he tags giving consistent labels to his\n> intermediate builds. e.g. as in:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING\n> \n> Or he may want to have Git force him to also supply a log message along\n> with a tag, so that he can remember later more accurately why a tag was\n> created and what it really captures. Even if Git (or other SCM systems)\n> don't natively support log messages on tags. Scmbug plans to implement\n> this.\n\nGit supports using tags for a variety of other purposes in addition to the \ntraditional ones (for example, you can tag a version as \"the changes I'm \nsure of\" or \"the version I know is broken\"; furthermore, your regression \ntesting system could give you a tag that tags the commit you sent for \ntesting with the test results). The bug tracker integration should only \ncare about the traditional use (providing a persistant, human-recognizable \nname for a revision). Actually, it would probably be best, for integration \nwith git, to skip tags entirely, and use the hash. With projects using \ngit, it is routine to know that the bug was found in some particular \nflawed commit that didn't get tagged.\n\n> http://bugzilla.mkgnu.net/show_bug.cgi?id=219\n> \n> \n> (2) I would like to apply various verification policies when work from a\n> local repository is finally merged with the central repository. I assume\n> there can/will be a central repository, and there is one \"software\n> product\" that is being released somewhere among the many copies.\n> \n> When its time to merge local changes to a central repository, the\n> verification policies may deem that changes are not acceptable to be\n> merged with the mainline. e.g. because log messages are too short,\n> commits during the merge are issued against bugs in \"a central\"\n> bugtracker that are either closed, assigned to someone else, or just\n> plain wrong bug-numbers that belong to other products:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME\n> \n> (I'm not very clear whether this is how Git works)\n> \n> Does someone get to write-up a brand new log comment during the merge\n> and the merge totally disregards older log comments ? My understanding\n> is that log comments on the local copy are preserved (and will need to\n> be mapped to bug-numbers in the central bug-tracker. \n\nIn general, you send to the central repository, and it rejects you if (a) \na merge would be required; you have to fetch and merge in your local \nrepository; or (b) there's something wrong with the changes you're making.\n\nFor (a), you make a merge commit and try again; the new commit has a log \nmessage, but the old commits retain their log messages. For (b), you make \na different set of commits that does follow the required policy. \"git \nrebase -i origin/master\" will guide you through this process. In general, \nyou do this before sharing your changes with anybody else, or at least \nbefore sharing them with anyone who cares about the end result, so that \nother people see nice commits. It's also possible to rearrange the changes \nyou made in a bunch of local commits into a series that looks nice and \nmakes sense and follows the project rules, when your initial work had you \nintroducing a lot of silly mistakes and fixing them.\n\n> Thus the local verification policies may need to have already been\n> configured to comply with future verification policies of the central\n> repository. Else (perhaps considerable) mappings/adjustments will be\n> needed during the push to the central copy.\n\nIn general, there's a ton of adjustment needed between working on a \nproject and pushing to the central location in any system. With git, \nhowever, version control may be used locally before these adjustments are \nmade, and this provides a huge benefit in terms of being able to prepare \ncommits just how they should be, and in terms of being able to avoid \nlosing work during the adjustments.\n\nIn general, you want to have a local understanding of the central \nrepository rules, so that you can do this mapping while you don't have \nnetwork, but there's no reason to prevent saving your work before it \nconforms.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"93227","messageId":"20081016201502.GA6362@efreet.light.src","threadId":"15796","inReplyTo":"1224007401.4073.40.camel@localhost","subject":"Re: Git and tagging hook","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-10-16T20:15:02Z","receivedAt":"2008-10-16T20:15:02Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 14, 2008 at 11:03:21 -0700, Kristis Makris wrote:\n> I have two use cases:\n> \n> (1) A developer maintains besides his local copy a local bug-tracking\n> system in which he tracks his changes. We would like to apply various\n> verification policies when he commits or tags. For example, for tagging\n> we wants to ensure that he tags giving consistent labels to his\n> intermediate builds. e.g. as in:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING\n\nThat already requires using additional interface to git alone. Using an alias\nfor creating tags that are synchronized with that local bug-tracker is not\nthat much more complex than IMHO. Besides you will sometimes want to use git\ntags, branches, commits and other things *without* synchronizing them to the\nlocal bug-tracker even if you usually synchronize -- they are often very\nuseful for manipulating changes.\n\n> Or he may want to have Git force him to also supply a log message along\n> with a tag, so that he can remember later more accurately why a tag was\n> created and what it really captures. Even if Git (or other SCM systems)\n> don't natively support log messages on tags. Scmbug plans to implement\n> this.\n> \n> http://bugzilla.mkgnu.net/show_bug.cgi?id=219\n\nGit does support log messages on tags. It has unannotated tags (which are\njust refs) and annotated tags which have a special tag object with the log\nmessage (and optionally PGP signature).\n\n> (2) I would like to apply various verification policies when work from a\n> local repository is finally merged with the central repository. I assume\n> there can/will be a central repository, and there is one \"software\n> product\" that is being released somewhere among the many copies.\n> \n> When its time to merge local changes to a central repository, the\n> verification policies may deem that changes are not acceptable to be\n> merged with the mainline. e.g. because log messages are too short,\n> commits during the merge are issued against bugs in \"a central\"\n> bugtracker that are either closed, assigned to someone else, or just\n> plain wrong bug-numbers that belong to other products:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER\n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME\n> \n> (I'm not very clear whether this is how Git works)\n> \n> Does someone get to write-up a brand new log comment during the merge\n> and the merge totally disregards older log comments? My understanding\n> is that log comments on the local copy are preserved (and will need to\n> be mapped to bug-numbers in the central bug-tracker. \n\nIndeed, the locally made commits are transfered to the upstream repository as\nthey are. In fact, because the commit id is a SHA1 checksum of all it's\ncontent, including the message and the parent ids (and therefore complete\nhistory), when the commit message is changed, it is no longer the same\ncommit.\n\nHowever, git provides many tools (commit --amend, rebase -i, filter-branch)\nand has additional extensions (stgit, topgit), that make it easy to create\na new commit based on another one with some change. This is extremely useful\nand many people use it really often.\n\nSuch new commit will not replace the previous one -- it has different\nchecksum -- so it's not good thing to do when other people already based\nfurther changes on your commit. But it's very useful for handling work in\nprogress, quickly diverting to different tasks, making experiments and such.\n\nTherefore it's the push that casts things in stone, but before that you can\neasily take back and redo both commits and tags. Additionally it's very\nuseful to sometimes do commits and tags that you intend to replace later just\nto temporarily record some interesting state eg. to divert to other bug that\nsuddenly got higher priority or to try out different approach.\n\nThus you only want to run the checks as warnings locally and probably want to\nhave an option to avoid them in a particular case for performance reasons\n(all this stuff is so useful because it's fast). And since the tags that are\nment for publication you will usually pull shortly after making them and\nbecause creating a tag is rather simple, I would say that running the check\non push is sufficient there and the alias helps if you'd really want to run\nthe check earlier. For commits you can of course use the pre-commit and\npost-commit hooks.\n\n> [...]\n> The local tag is useful to the local user and his local bug-tracker. He\n> can have tag operations intercepted so that the tag names show up as\n> versions in his bug-tracker. In this way he can keep track of which bugs\n> still exist or have recently been introduced/discovered to his local\n> copy, before he decides to publish his polished, final version:\n> \n> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS\n> \n> And his \"local bug-tracker\" may be reachable on the web and useful by\n> others that take a peek at the users progress (even fetching it with\n> Git).\n\nI would rather recommend having per-developer branches (you can actually have\nbranch hierarchies, so it's rather per-developer branch directories) on the\ncentral repo, where the users would push their work they consider final\nenough to show to anybody. Than you can have a \"pending\" (or \"for review\" or\nboth or whatever) state in the central bug-tracker for issues with fixes on\nsuch developer branches. That saves the hassle of installing per-developer\ntrackers and gives developer more freedom to create temporary stuff locally.\n\nThat is not to say that your use case makes no sense. I am just trying to\nsuggest a workflow, that might fit better with the existing practices used\nwith git and maybe requiring less work to implement.\n\nAs for people replacing their local commits, this is common especially in\nLinux (and Git) development model. For Linux patches need to be sent split\ninto logical steps to make it easier to review them, which is quite important\nfor a critical piece of code like kernel. But everybody will inevitably make\nmistakes when implementing the changes; these mistakes must not appear in the\nfinal submission though, because they would interfere with review. When\ndeveloping in Git, each commit will produce one patch in the submission, so\npeople go and redo their commits multiple times to make them as much readable\nas possible and fix bugs they made earlier.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"93268","messageId":"48F83914.8080508@op5.se","threadId":"15796","inReplyTo":"20081016201502.GA6362@efreet.light.src","subject":"Re: Git and tagging hook","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-17T07:04:52Z","receivedAt":"2008-10-17T07:04:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jan Hudec wrote:\n> As for people replacing their local commits, this is common especially in\n> Linux (and Git) development model.\n\nIt's common everywhere where projects use peer review.\n\nResults 1 - 50 of about 14,600 for '\"PATCH v2\" vger.kernel.org'\nResults 1 - 50 of about 360,000 for \"PATCH v2\"\n\nSo yes, it is a very common practice and anything interacting with a remote\ndatabase based on each commit action will almost certainly be doing something\nwrong quite a lot of the time, especially since not all the patch-series end\nup being incorporated into a release anyway.\n\nThe only sane integration point is the public watering-hole repository used\nfor the project, and especially the release branch (or the \"for-linus\" branches\naround the world for sub-projects).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}