Very curious if this is on the horizon. This is something I've taken for granted the last decade or so with repositoryhosting.com, for example.
On any distributed team that is large at all (not to mention multi-OS), having individual users running complex programs on triggers is not feasible. Also, just trying to update the email lists for them all would be infeasible -- some email addresses are not intended to be shared with every contractor with commit rights, but their commits should still go into the pool, etc.
I don't think this needs to be super overengineered. Essentially, a few basics would accomplish most things:
- Does a plastic scm cloud user have access to a project? Was there a checkin to the project? Email them unless they opt out.
You can get fancier with things like email addresses that are not part of the list of cloud users, or you could get into things like branches only going to be people related to the branch, but this is not too terribly critical for small and midsize teams.
Very curious if this is on the horizon. This is something I've taken for granted the last decade or so with repositoryhosting.com, for example.
On any distributed team that is large at all (not to mention multi-OS), having individual users running complex programs on triggers is not feasible. Also, just trying to update the email lists for them all would be infeasible -- some email addresses are not intended to be shared with every contractor with commit rights, but their commits should still go into the pool, etc.
I don't think this needs to be super overengineered. Essentially, a few basics would accomplish most things:
- Does a plastic scm cloud user have access to a project? Was there a checkin to the project? Email them unless they opt out.
You can get fancier with things like email addresses that are not part of the list of cloud users, or you could get into things like branches only going to be people related to the branch, but this is not too terribly critical for small and midsize teams.