On 09/23/2015 04:40 AM, Todd Goodman wrote: > > We haven't had too many problems with it. Most of our problems seem to > be with people having issues with git itself (it was new to almost > everyone on the team) and not embracing a good workflow with it (or > trying to only use git via Eclipse.) > > We have 80 or so Android repos and a much smaller handful of proprietary > repos in use. >
Sorry to harp on this, but does your single gerrit user have write access to all 80 of your repos? Yours is internal so the risk is limited, but naturally, if we set one up, it would have to be public. If there's a bug in the web UI somewhere and someone figures out how to make it run code, that would put all of our repos at risk. Even without being able to run code, a bug might allow privilege escalation: someone outside the e.g. portage project might figure out how to push to that repo because all of the logic is in Java and not the filesystem. The way we have it now, push access is granted through SSH and is therefore tied to your user. Implementing users/groups/permissions in code would really be a step backwards; this isn't a theoretical argument. These issues can totally be fixed -- I'm not saying they're endemic to web-based git hosting. But to move access control down to the filesystem deviates from how everyone else does things. So first you need to spend time getting familiar with the project, then you have to overhaul the way it works, and finally you have to get upstream to acknowledge that you aren't crazy and accept your docs/patches. That's a lot more work than just setting it up.