On Thu, Nov 8, 2012 at 1:17 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > 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? Just for the E-Mail to include a link to http://gitweb.example.com/git/....?h=$our_hash etc. >> * 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 just sending the individual patch e-mails to all people who subscribe to paths that got changed in that patch that match their watchlist makes sense. That's how an internal E-mailing script that I'm hopign to replace with this works. That script *also* supports sending the whole batch of patches pushed in that push to someone watching any file that got modified in one of the patches, in case you also want to get other stuff pushed in pushes for files you're interested in. But it doesn't generate individual E-Mails per recipient. I think that way lies madness because as you rightly point out you have to start worrying about the combinatorial nightmare of generating the E-mails per subscriber. >> 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). -- 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