On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote: > [...] I'm glad it's getting some use. Thanks for the feedback. > I'll test it out some more, the issues I've had with it so far in > migrating from the existing script + some custom hacks we have to it > have been: > > * Overly verbose default templates, easy to overwrite now. Might send > patches for some of them. The templating is currently not super flexible nor very well documented, but simple changes should be easy enough. I mostly carried over the text explanations from the old post-receive-email script; it is true that they are quite verbose. > * No ability to link to a custom gitweb, probably easy now. What do you mean by "a custom gitweb"? What are the commitmail issues involved? > * If someone only pushes one commit I'd like to only have one e-mail > with the diff, but if they push multiple commits I'd like to have a > summary e-mail and replies to that which have the patches. > > It only seemed to support the latter mode, so you send out two > e-mails for pushing one commit. That's correct, and I've also thought about the feature that you described. I think it would be pretty easy to implement; it is only not quite obvious to which mailing list(s?) such emails should be sent. > * Ability to limit the number of lines, but not line length, that's > handy for some template repositories. Should be easy to add Should too-long lines be folded or truncated? Either way, it should be pretty straightforward (Python even has a textwrap module that could be used). > But in addition to that we have our own custom E-Mail notification > scripts for: > > * People can subscribe to changes to certain files. I.e. if you > modify very_important.c we'll send an E-Mail to a more widely seen > review list. > > * Invididuals can also edit a config file to watch individual files / > glob patterns of files, e.g. src/main.c or src/crypto* I implemented something like this back when we were using Subversion, but it didn't get much use and seemed like more configuration hassle than it was worth. If this were implemented and I asked for notifications about a particular file, and a particular reference change affects the file, what should I see? * The summary email for the reference change (yes/no)? * Detail emails for all commits within the reference change, or only for the individual commits that modify the file? * Should the detail emails include the full patch for the corresponding commit, or only the diffs affecting the file(s) of interest? (The latter would start to get expensive, because the script would have to generate individual emails per subscriber instead of letting sendmail fan the emails out across all subscribers.) > I think a good way to support that would be to have either a path to a > config file with those watch specs, or a command so you could run "git > show ..." on some repo users can push to. *How* this feature would be configured depends strongly on how the repo is hosted. For example, gitolite has a well-developed scheme for how the server should be configured, and it would make sense to work together with that. Other people might configure user access via LDAP or Apache. > But overall it's very nice. I'll make some time to test it in my > organization (with lots of commits and people reading commit e-mails). Cool, thanks! Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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