{"thread":{"id":"16832","subject":"[RFC] Automagic patch merge ack emails","startedAt":"2008-12-22T14:07:07Z","lastAt":"2008-12-23T14:46:27Z","messageCount":4,"participants":["Richard Hartmann","Junio C Hamano","Boyd Stephen Smith Jr."],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98544","messageId":"2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com","threadId":"16832","inReplyTo":null,"subject":"[RFC] Automagic patch merge ack emails","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-12-22T14:07:07Z","receivedAt":"2008-12-22T14:07:07Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\nI poked around the docs, but I could not find any option to have git\nsend email to people who signed off a patch when it's merged.\nI only realized the two patches I sent were merged because they were\nlisted in the RC changelog summary and would have followed up my patch\nemail in a about a week, asking about its status.\n\nDoes anyone else think this is useful? Does anyone else think it should\nmake it into main so it can be enabled via config, not via a hook that\nneeds to be imported into each and every repo?\n\n\nRichard\n"},{"id":"98553","messageId":"7v8wq8hs34.fsf@gitster.siamese.dyndns.org","threadId":"16832","inReplyTo":"2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com","subject":"Re: [RFC] Automagic patch merge ack emails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-22T20:29:03Z","receivedAt":"2008-12-22T20:29:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Richard Hartmann\" <richih.mailinglist@gmail.com> writes:\n\n> I poked around the docs, but I could not find any option to have git\n> send email to people who signed off a patch when it's merged.\n\nThe correcty way to say that \"the changes from a patch get incorporated\"\nis \"it's applied\", not \"merged\".  There is no \"post-am\" hook you can use\nto make an announcement.  Nor the sample post-commit hook that is called\nafter every commit mentions anything about e-mails.\n\nAnd these are good things, and here is why.\n\nIt does not matter a whit to you if/when I applied your patch to a topic\nbranch in my private repository that I work in, preparing for eventual\npushout to the public tree.  Patches are reviewed in e-mail form, and\nobvious typos and logic mistakes are corrected while still I am reading\nyour patch in my MUA, if they are trivial (otherwise you will get a reply\nsaying to which points I do not agree with your patch).  After your patch\npasses this process, it may be applied somewhere, perhaps directly on\n'master' or 'maint', or perhaps on a new topic branch to house your\nchanges.\n\nBut that is only the beginning of the story.  I'll apply many more changes\nfrom other people, testing each step, rebasing and amending these changes\nas necessary to fix breakages, and I may realize that some patches are not\nquite ready to be in the public history during this process.  Your patches\nmay be part of these patches discarded that way.\n\nWhen I decide not to apply your patch (iow, it hits my mailbox but I\nreject it while it is in my MUA), git obviously would not know about it at\nall [*1*].\n\nEven after I apply your patch somewhere, I may decide not to include it in\nin any of the public branches after testing and re-reviewing.  I may merge\nthe topic branch I created to host your patch to 'next', but after testing\nand re-reviewing, I may decide it is not ready, and I'd rebuild 'next'\nwithout the topic before pushing the results out.  And I'd delete such a\ntopic branch after I am done with it.\n\nWhat this means is that the time a commit is made (either by patch\napplication or \"git pull\" from somebody else's tree) is too early to make\nany announcement.  \"git am\" hook would not be useful for that purpose.\n\nThe only time that it may make a difference to you is when things are\npushed out to the public repository, and there is a mechanism for\nautomating tasks after new commits hits the public repository: the\npost-receive hook.  contrib/hooks/post-receive-email may be a good example\nto study if you are interested (I use it in my day job repository, but I\ndo not use the hook in git.git because the style of announcing I adopted\non this list is to send out \"What's in/cooking\" messages once or twice a\nweek).\n\n> Does anyone else think this is useful? Does anyone else think it should\n> make it into main so it can be enabled via config, not via a hook that\n> needs to be imported into each and every repo?\n\nIf your \"each and every\" repository is used for the same uniform purpose\n(namely, publishing to the public), then they can be initialized with the\nsame hook scripts using the templates mechanism, so in a sense, there\nalready is a mechanism for that.\n\nBut it is very unlikely your repositories are uniform, so I doubt that the\nmechanism based on custom templates, or your built-in announcement\nmechanism triggered by configuration, would be very useful.\n\nMost of the freedom in a DVCS workflow comes from the separation between\nmaking commits (including patch application and merges) and publishing the\nresult.  You do not want to fear committing crap, because you can\ncarefully check the result before making it public.\n\nBecause of that, private repositories where the real work takes place and\npublic repositories that serve as distribution points have very different\nneeds.  You do not want to have any announcement triggers in the former\n(that's the whole point of separating \"making commits\" and \"publishing the\nresult\"), while some people like announcement triggers in the latter.\n\n[Footnote]\n\n*1* There are two kinds of patches that rejected that way.\n\n * One with good intention but wrong execution receives suggestion for\n   improvements.\n\n * One with misguided intention or misleading description is requested to\n   clarify why the change is needed, before receiving comments on the\n   implementation.\n"},{"id":"98558","messageId":"200812221459.30728.bss@iguanasuicide.net","threadId":"16832","inReplyTo":"2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com","subject":"Re: [RFC] Automagic patch merge ack emails","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2008-12-22T20:59:26Z","receivedAt":"2008-12-22T20:59:26Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Monday 2008 December 22 08:07:07 Richard Hartmann wrote:\n> I poked around the docs, but I could not find any option to have git\n> send email to people who signed off a patch when it's merged.\n\nThere's not one, since something that that should probably be done in a hook.  \nMaybe the update hook?\n\n> I only realized the two patches I sent were merged because they were\n> listed in the RC changelog summary and would have followed up my patch\n> email in a about a week, asking about its status.\n>\n> Does anyone else think this is useful?\n\nI think it would be nice to get a notification whenever Junio pushes commits \nto 'master' or 'maint' in git.git if I've signed off on one of the commits.  \nI don't think everyone would though so the hook would need to be maintained \nindefinitely (updating the email blacklist, etc.).\n\nIt would probably be a nice hook to have as an example, I guess.\n\n> Does anyone else think it should \n> make it into main so it can be enabled via config, not via a hook that\n> needs to be imported into each and every repo?\n\nDefinitely not.  It's not that difficult to add a hook to the repositories \nthat need it, and I think the majority of repositories will be private and \nnot need it.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"98615","messageId":"2d460de70812230646r181f59d0y55055e96ad6eda84@mail.gmail.com","threadId":"16832","inReplyTo":"7v8wq8hs34.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Automagic patch merge ack emails","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-12-23T14:46:27Z","receivedAt":"2008-12-23T14:46:27Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Mon, Dec 22, 2008 at 21:29, Junio C Hamano <gitster@pobox.com> wrote:\n\n> The only time that it may make a difference to you is when things are\n> pushed out to the public repository, and there is a mechanism for\n> automating tasks after new commits hits the public repository: the\n> post-receive hook.  contrib/hooks/post-receive-email may be a good example\n> to study if you are interested (I use it in my day job repository, but I\n> do not use the hook in git.git because the style of announcing I adopted\n> on this list is to send out \"What's in/cooking\" messages once or twice a\n> week).\n\nThat's pretty much what I meant, yes. As to the rest, I am still thinking\ntoo much in VCS, not DVCS, style, I guess.\nThanks for your clarification, it all makes sense, now :)\n\n\nRichard\n"}]}