{"thread":{"id":"6800","subject":"[PATCH 2/3] Only show log entries for new revisions in hooks--update","startedAt":"2007-02-13T14:24:06Z","lastAt":"2007-02-13T18:08:17Z","messageCount":3,"participants":["Andy Parkins","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"34407","messageId":"200702131424.06983.andyparkins@gmail.com","threadId":"6800","inReplyTo":null,"subject":"[PATCH 2/3] Only show log entries for new revisions in hooks--update","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-13T14:24:06Z","receivedAt":"2007-02-13T14:24:06Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"If you were issuing emails for two branches, and one merged the other,\nyou would get the same log messages appearing in two separate emails.\n\ne.g. A working repository, where the last push to central was done at\n     the revision marked \"B\", after which two branches were developed\n     further.\n\n  * -- B -- 1 -- 1 -- M (branch1)\n        \\           /\n         2 -- 2 -- 2 (branch2)\n\nNow imagine that branch2 is pushed to the email-generating repository;\nan email containing all the \"2\" revisions would be sent.  Now, let's say\nbranch1 is pushed, the old update hook would run\n\n git-rev-list $newrev ^$baserev\n\nWhere $newrev would be \"M\" and $baserev would be \"B\".  This list\nincludes all the \"2\" revisions as well as all the \"1\" revisions.\n\nThis patch addresses this problem by using\n\n git-rev-parse --not --all | git-rev-list --stdin $newrev ^$baserev\n\nTo inhibit the display of all revisions that are already in the\nrepository.\n\nSigned-off-by: Andy Parkins <andyparkins@gmail.com>\n---\n templates/hooks--update |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/templates/hooks--update b/templates/hooks--update\nindex e8c536f..7e8258a 100644\n--- a/templates/hooks--update\n+++ b/templates/hooks--update\n@@ -190,7 +190,7 @@ case \"$refname_type\" in\n \t\t\tfi\n \t\t\techo \"\"\n \t\t\techo $LOGBEGIN\n-\t\t\tgit-rev-list --pretty $newrev ^$baserev\n+\t\t\tgit-rev-parse --not --all | git-rev-list --stdin --pretty $newrev ^$baserev\n \t\t\techo $LOGEND\n \t\t\techo \"\"\n \t\t\techo \"Diffstat:\"\n-- \n1.5.0.rc4.364.g85b1\n"},{"id":"34432","messageId":"7vbqjyymye.fsf@assigned-by-dhcp.cox.net","threadId":"6800","inReplyTo":"200702131424.06983.andyparkins@gmail.com","subject":"Re: [PATCH 2/3] Only show log entries for new revisions in hooks--update","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-13T17:41:29Z","receivedAt":"2007-02-13T17:41:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I seem to recall that something like this was discussed recently\non the list.\n\nWhile excluding commits on already updated branches works if the\nsame set of recipients receive e-mails for both branches by\neliminating the duplicates, I suspect that in more elaborate\nsettings people would want to do different notices for different\nbranches, and for that kind of usage people who subscribes only\nto branch1 in your picture would miss what happened on branch2.\n\nOr maybe branch1 is the main integration branch (e.g. 'master',\n'next') while branch2 is a tentative topic that does not send\nout notification e-mails.\n\nIf we want to take this example hook seriously, I suspect that\nthe existing mechanism based on hooks.* variables might need to\nbe made to allow finer grained, per-branch, control.  I dunno.\n\nPost 1.5.0.\n"},{"id":"34450","messageId":"200702131808.19291.andyparkins@gmail.com","threadId":"6800","inReplyTo":"7vbqjyymye.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/3] Only show log entries for new revisions in hooks--update","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-13T18:08:17Z","receivedAt":"2007-02-13T18:08:17Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, February 13, Junio C Hamano wrote:\n\n> If we want to take this example hook seriously, I suspect that\n> the existing mechanism based on hooks.* variables might need to\n> be made to allow finer grained, per-branch, control.  I dunno.\n>\n> Post 1.5.0.\n\nAbsolutely - per-branch sounds great.  However, as that is definitely a \npost-1.5.0 topic, I wanted to get the hook that was there in better \nshape for the release.\n\nUntil the per-branch work is done, I think this patch is worth having.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"}]}