"Richard Hartmann" <richih.mailinglist@xxxxxxxxx> writes: > I poked around the docs, but I could not find any option to have git > send email to people who signed off a patch when it's merged. The correcty way to say that "the changes from a patch get incorporated" is "it's applied", not "merged". There is no "post-am" hook you can use to make an announcement. Nor the sample post-commit hook that is called after every commit mentions anything about e-mails. And these are good things, and here is why. It does not matter a whit to you if/when I applied your patch to a topic branch in my private repository that I work in, preparing for eventual pushout to the public tree. Patches are reviewed in e-mail form, and obvious typos and logic mistakes are corrected while still I am reading your patch in my MUA, if they are trivial (otherwise you will get a reply saying to which points I do not agree with your patch). After your patch passes this process, it may be applied somewhere, perhaps directly on 'master' or 'maint', or perhaps on a new topic branch to house your changes. But that is only the beginning of the story. I'll apply many more changes from other people, testing each step, rebasing and amending these changes as necessary to fix breakages, and I may realize that some patches are not quite ready to be in the public history during this process. Your patches may be part of these patches discarded that way. When I decide not to apply your patch (iow, it hits my mailbox but I reject it while it is in my MUA), git obviously would not know about it at all [*1*]. Even after I apply your patch somewhere, I may decide not to include it in in any of the public branches after testing and re-reviewing. I may merge the topic branch I created to host your patch to 'next', but after testing and re-reviewing, I may decide it is not ready, and I'd rebuild 'next' without the topic before pushing the results out. And I'd delete such a topic branch after I am done with it. What this means is that the time a commit is made (either by patch application or "git pull" from somebody else's tree) is too early to make any announcement. "git am" hook would not be useful for that purpose. The only time that it may make a difference to you is when things are pushed out to the public repository, and there is a mechanism for automating tasks after new commits hits the public repository: the post-receive hook. contrib/hooks/post-receive-email may be a good example to study if you are interested (I use it in my day job repository, but I do not use the hook in git.git because the style of announcing I adopted on this list is to send out "What's in/cooking" messages once or twice a week). > Does anyone else think this is useful? Does anyone else think it should > make it into main so it can be enabled via config, not via a hook that > needs to be imported into each and every repo? If your "each and every" repository is used for the same uniform purpose (namely, publishing to the public), then they can be initialized with the same hook scripts using the templates mechanism, so in a sense, there already is a mechanism for that. But it is very unlikely your repositories are uniform, so I doubt that the mechanism based on custom templates, or your built-in announcement mechanism triggered by configuration, would be very useful. Most of the freedom in a DVCS workflow comes from the separation between making commits (including patch application and merges) and publishing the result. You do not want to fear committing crap, because you can carefully check the result before making it public. Because of that, private repositories where the real work takes place and public repositories that serve as distribution points have very different needs. You do not want to have any announcement triggers in the former (that's the whole point of separating "making commits" and "publishing the result"), while some people like announcement triggers in the latter. [Footnote] *1* There are two kinds of patches that rejected that way. * One with good intention but wrong execution receives suggestion for improvements. * One with misguided intention or misleading description is requested to clarify why the change is needed, before receiving comments on the implementation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
