<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2019 at 12:38 PM Troy A. Griffitts <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><p>The primary reason I haven't switched this yet is that we have
many people with access to various parts of that repo. Some can
modify tests, some the build system, some filters, only a few can
modify the core lib source, etc. I don't want to control all the
merge requests to that repository. People have been delegated the
authority to manage their parts of the tree and have full write
permissions. I get emails when people commit and can view their
diffs in the emails. I regularly review what is committed and
comment if I feel the need. I don't have a good solution for this
access management with git. I know how git would suggest I do
it. Let everyone fork, modify their fork, and submit pull
requests. But then I become the bottleneck if I don't merge in a
timely fashion, and also I have to remember who has access to
what, "Should this person have permission to change this or
that." With SVN we have an access file which contains groups of
files named appropriately and we grant contributes full write
access to the level and portions we are comfortable letting them
have full write access to those portions of the authoritative
repository.</p></div></blockquote><div><br></div><div>The solution to this is a githook. A git hook is an executable bit that runs during certain actions on a git repository. There are some that are only local (pre/post commit, pre/post push) and others that executed when a remote system attempts to push commits to the local repository.</div><div><br></div><div>In my work at SoftLayer, we had such hooks on the git server to prevent everyone except a few select people committing or pushing to the master branch. Likewise, we prevent pushing anything that included a file named ".htaccess" and from pushing to any branch that did not have an open JIRA issue in a few well-defined states. You could absolutely create one to enforce the same level of granularity that you're looking for. I have a little bit of experience with it, but I'm sure there are lots of tutorials out on the web that would tackle this better than I can. But, briefly:</div><div><br></div><div>In any git repo, you'll find the folder ".git/hooks" that includes a number of example hooks. The "update.sample" is an example of a hook that is called for each commit a client attempts to push to the repository. It is passed the refname (e.g. refs/heads/master), the sha hash of the current reference for that refname, and the sha hash the push is attempting to update to. If the ".git/hooks/update" file exists and is executable, it will be called with those three arguments as $1, $2, $3. If it exits with any non-zero value, the push will fail.</div><div><br></div><div>So a little bit of git foo in the "update" can list out all modified files in the current push and reject them if the user is modifying a file that they are not allowed access to.</div><div><br></div><div>As a basic example:</div><div>#!/bin/bash</div><div>ref="${1}"</div><div>old="${2}"</div><div>new="${3}"</div><div><br></div><div>if [ "${ref}" == "refs/heads/master" ]; then</div><div> for file in $(git diff --name-only "${old}..${new}"); do</div><div> # check $file for user's access</div><div> done</div><div>fi</div><div><br></div><div>There's lots more git foo in there to find out who authored each commit or who is making the push, if they have permissions, etc. Because, in git, I might be pushing a branch with changes to something I'm allowed but the commit might be authored by someone else and I've just signed off on it. Lots more info is out there and it's probably specific to our Gitlab configuration how to get info about the person doing the push. But, this is definitely possible.</div><div><br></div><div>--Greg<br></div></div></div>