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

>  * 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

> 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 Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to