GitHub PushEvent at 2014-05-28 20:39:27
Repository: git-multimail
Actor: newren
Payload: {"shas":[["f34b27b51bc8f8717c90538d66e7f70fa1e1e43f","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","Emit single pushed commit as just a single email\n\nNo need to send both a refchanged email and commit email.\n\nIn the sadly-all-too-frequent usecase of people pushing only one of their\ncommits at a time to a repository, users feel the reference change summary\nemails are noise rather than important signal.  This is because there is a\nreference change summary email for each new commit, and all these\nsummaries do is point out that there is one new commit -- something that\nis obvious from the existence of the individual revision email that is\nalso sent.  In such cases, users prefer there to be no push summary email.\n\nSome examples where this is particularly important:\n\n    Sadly, gerrit's review mechanism essentially enforces a workflow where\n    every commit is submitted individually (things can be directly pushed\n    if permissions are set up to allow it, but those pushes bypass the\n    code review mechanisms).  Users can push several commits at once for\n    review, but each commit is reviewed and submitted individually, and it\n    is upon submit that gerrit merges the commit onto the real branch.\n    This serialization means that gerrit's equivalent to the post-receive\n    hook (named ref-updated) gets fired off for just a single new commit\n    (well, two commits if you count the implicit merge commit created by\n    gerrit, but users find emails about the implicit gerrit merge commits\n    to be noise as well).\n\n    Lots of people haven't weaned themselves from a cvs- or svn-like\n    workflow may also push each commit individually.  For people who\n    predominantly only push a single new commit, the push summary emails\n    are just noise.\n\nHowever, even in repositories where 98% of uses are one of the above,\nthere are still other folks that might sometimes do large merges between\nbranches, or push several commits at once, or potentially force update\nsome branches.  In all of these cases, the reference summary emails are\nvery useful and we still want them to be sent, so we do not want to just\nturn off the reference summary emails on a repo-by-repo basis.  We instead\nwant to have them turned off just for the particular pushes for which\nusers deem them to be noise.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",false],["6882073e8b9b00dd5a9670a9cf3111d5e1f22107","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","Add a get_ref_ignore_list() function to allow refs to be ignored\n\nSome deployments may have refs for which they don't want emails sent out\nwhen they are updated.  However, if commits pushed to these refs are later\npushed to another ref, we do want emails for those commits at that time.\nThis means that these refs should be ignored both in terms of which\nchanges we should send out emails for, and when computing what commits are\nconsidered new to the repository.\n\nWe set the default for this in the base Environment to [\"refs/notes/\"].\nA default of [] would make sense if git_multimail had a specialized\nformatting for commits made by git notes, but it currently doesn't.  In\nparticular, the commit messages of git notes are essentially meaningless\nand \"filenames\" in git notes commits are merely an implementational\ndetail.  As such, sending emails for these commits, with our current\nformat, is suboptimal.\n\nNotes are not the only reason for an exclusion, though.  For example,\nGerrit uses refs/changes/ to store commits that have not yet been vetted.\nUsers think of commits stored under refs/changes/ as being new to the\nrepository only when they are finally merged into a branch under\nrefs/heads/.  (There are a variety of reasons for this: (a) these commits\nhaven't undergone code review and thus are viewed as not yet having been\naccepted, (b) Gerrit has a separate mechanism to handle things pushed to\nrefs/changes/ (emailing just a few relevant folks with a message along\nthe lines of \"You have a Change Review that you need to look at; look at\nthis nifty web page to add your comments.\"), (c) only a small subset of\nusers are interested in any particular refs/changes/ push, whereas\nhundreds of developers want to see what enters refs/heads/, (d), gerrit's\nstandard ref-updated hook, which is similar to git's update or\npost-receive hooks, is not invoked for these refs.  It all adds up to\nreasons to ignore this particular ref namespace.)  Another example is\nGerrit's refs/cache-automerge/, which is essentially just an\nimplementational detail that we clearly don't want to spam users about.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["f985100075dbaa9c9af1d17b64d3794c0eddd0eb","955405675e5ddb1a110d200661c528aa223ef60f@gmail.com","Allow sending emails only for a subset of refs\n\nMany projects use a pull-request model with a central repository, where\nnew changes are pushed to branches named e.g. feature/whizbang.  However,\nusers really don't view these branches as \"part of the repository\" until\nthey are merged into a 'real' branch, such as master.  And lots of users\nare very annoyed at getting email notifications for pushes to these\nbranches; they only want to be notified when some subset of branches are\nupdated.\n\nThere's a slight complication, though: traditionally git-multimail has\nonly sent out commit emails for commits that are entirely new to the\nrepository, but this doesn't play well with this filtering feature.  So,\nwe need to instead have git-multimail only send out commit emails for\ncommits that are entirely new to the *relevant subset of the* repository.\n\nAdd multimailhook.refFilterInclusionRegex and\nmultimailhook.refFilterExclusionRegex configuration options, with related\n--ref-filter-inclusion-regex and --ref-filter-exclusion-regex command\nline options, which can be used to configure which refs are considered\nrelevant.  Mark ^refs/notes/ as irrelevant by default as git-multimail\nemails make no sense for git notes.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["12216bb3fddabdc6098ae4fdbdfc696605e90611","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","GerritEnvironment: Make git_multimail callable as Gerrit ref-updated hook\n\ngit_multimail has the ability to be directly called as either a git update\nor git post-receive hook.  Add the ability for git_multimail to be called\nas a Gerrit ref-updated hook (Gerrit does not implement the standard git\nhooks), and provide a GerritEnvironment (similar to GitoliteEnvironment\nor GenericEnvironment) with relevant defaults.\n\nGerrit users are probably slightly less likely to use git_multimail since\ngerrit already has a built-in email capability.  However:\n  * Gerrit's emails appear to only trigger for references submitted as CRs\n    (e.g. pushed to the magic refspec refs/for/), not for commits directly\n    pushed to the relevant branch.\n  * Some sites may have multiple git servers installed (e.g. Gitolite,\n    Gerrit, Atlassian Stash) and want similar email styles used regardless\n    of which system the repository is hosted under.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["1453e5a5dfe545983ab7ee8d43914f6b18810faa","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","GerritEnvironment: Skip merge commits created internally by Gerrit\n\nGerrit often creates a merge behind the scenes for an approved code\nreview.  Since it's a behind the scenes implementational detail, users\naren't necessarily interested in getting an individual email for each of\nthese.  Filter them out.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["ac358874e9f5a7936ac24b7b7067361d44a29de4","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","GerritEnvironment: Commits can enter repositories multiple ways\n\nSince commits can both be directly 'pushed' to the repository, or first\nbe created as a patchset and then 'submitted' from the web UI (with the\nlatter far more common), claiming that all gerrit commits were 'pushed'\nwill confuse users.  Make an \"update_method\" value available for\ntemplates so that emails can use the correct verb.\n\nThis would also apply to Stash, if it provided a way to differentiate\nin its (Async)?PostReceiveRepositoryHook classes between being\ntriggered by a direct push and by the merge of a pull request.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["31b6966332295f06280a54097e935968a8d29e26","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","GerritEnvironment: Work around rude discarding of submitter identity\n\nWe want to know who pushes/submits code to the repository, because that\ninformation is included in the emails.  However, Gerrit often rudely\ndiscards this information upon calling its ref-updated hook.  When Gerrit\ndoesn't provide this information directly, try to grab it indirectly.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["dbd5beae7ce32f63623cc36e17e17584ff45f917","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","StashEnvironment: New environment for being called from Atlassian Stash\n\nAtlassian Stash can utilize a standard post-receive hook, and thus we\ncould use git_multimail as-is.  However, that is slightly suboptimal\nbecause: (a) when pull requests are merged in stash, they are done on the\nserver and thus the normal post-receive hook is not triggered, (b)\neverything runs as a single user similar to gitolite, but without a\nGL_USER environment variable to rely on, and (c) although stash has\nreasonable clone urls that having meaningful names for repositories, the\nactual on-disk directories in which the repositories are stored are given\npositive integers for names -- that results in a rather meaningless email\nsubject for the users (\"[2093] branch master updated...\" rather than\n\"[PROJ/REPO] branch master updated...\"), since they will have no idea what\nmagic integer happened to be selected for their repository.\n\nWe can avoid these problems by making use of Stash's\nAsyncPostReceiveRepositoryHook instead of a standard post-receive hook,\nsince it is triggered in all the right cases and has access to the\nappropriate user and repo name.  Add a StashEnvironment for holding this\npassed information, and add command line flags that can be passed with\nthe user and repo name.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["e34493f93a0c8cb8aef29af6522a75676c496f10","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","GerritEnvironment, StashEnvironment: Make From=pusher by default\n\nI see no value in getting emails from\n   gerrit@<company-machine-no-one-needs-to-know-about>\nor\n   stash@<company-machine-no-one-needs-to-know-about>.localdomain\nThe default user.email setting is often far less than perfect, and having\nto set multimailhook.from for every repository is not ideal either.\n\nA default that makes more sense to me is that the email comes from the\nperson who pushed the change; for StashEnvironment we will always have\nthat information available and in GerritEnvironment we often will.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["df4cced40d8ff5e6dbf43b43097061e86cbd8c40","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","Atlassian Stash plugin: Initial version\n\nThis adds a plugin for Atlassian Stash that will run git_multimail as an\nAsyncPostReceiveRepositoryHook (similar to a standard post-receive hook,\nbut also fires for merges of pull-requests; further, via Stash's Java API\nsuch a hook has access to important data like user and repo name).\n\nThis plugin currently provides a single textbox entry of configuration at\nthe time that a repository owner enables the plugin, in which the\nrepository owner can provide a comma-separated list of email addresses\nthat they want the emails sent to.  Other multimail configuration options\nare unexposed through the web UI, though they can be configured on a\nrepository-by-repository basis on the server if an admin sets the\nappropriate multimailhook.* configuration setting in the git config file.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["a5ee9413f5cd298a341f32c782f5e828616827f2","ad90ed445ae20d2d2aaa642a601e669d4fcea2f4@palantir.com","Atlassian Stash plugin: Add logging capability\n\nSigned-off-by: Carl Myers <cmyers@palantir.com>\nSigned-off-by: Elijah Newren <newren@palantir.com>","Carl Myers",true],["53e499e767396183204810eb8751f52d880d93f1","ad90ed445ae20d2d2aaa642a601e669d4fcea2f4@palantir.com","Atlassian Stash plugin: Providing scaffolding for tests\n\nSigned-off-by: Carl Myers <cmyers@palantir.com>\nSigned-off-by: Elijah Newren <newren@palantir.com>","Carl Myers",true],["6e73a6070f53051610fc6a6461a325181fff7f1a","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","Atlassian Stash plugin: Expose ref filtering from the web UI\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["4adfc53872528ddf188dfc93cd57a37e7653d02c","bc587f234b6f55c2cf2257329a23353a53da9ab5@palantir.com","Atlassian Stash plugin: Default recipients list on project settings page\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Jerry Ma",true],["2b822484de760e6a16465825a5ec1c928a951ed5","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","RFC: Silence loud error messages going to the error log\n\nThis is the wrong way to do this.  For plain git installations, or\ngitolite installations, these messages are useful feedback sent to the\nuser when they do a push.  For stash, these messages are simply thrown\naway.  For gerrit, they spam the error log.  There's no way I know of to\nchange stash or gerrit to send these to the user, and as they aren't\nwarnings or errors but are just informational, it's really annoying to\nhave these spam the error log.  Having a more reasonable way to turn\nthese messages off would be nice.\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["c04434644759b83142b87079093ab41dca170bfa","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","[PALANTIR ONLY] Make FROM=AUTHOR for revision emails, as per Khan's request\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["12b23795d9dbb84b93bf8a48ce150cb9085ae93c","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","[PALANTIR ONLY] Link to local wiki in email footers\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true],["cd0e3d87e62c5c583b417b5985f2b3fddb291cc8","955405675e5ddb1a110d200661c528aa223ef60f@palantir.com","[PALANTIR ONLY] Provide link to web view of commit in email\n\nSigned-off-by: Elijah Newren <newren@palantir.com>","Elijah Newren",true]],"size":18,"ref":"refs/heads/master","head":"cd0e3d87e62c5c583b417b5985f2b3fddb291cc8"}