[sword-devel] Afrikaans [was: Translators Needed, Any Language]

[Greg Hellings]

On Wed, Jun 12, 2019 at 12:38 PM Troy A. Griffitts <scribe at crosswire.org>
wrote:

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

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.

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:

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.

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.

As a basic example:
#!/bin/bash
ref="${1}"
old="${2}"
new="${3}"

if [ "${ref}" == "refs/heads/master" ]; then
  for file in $(git diff --name-only "${old}..${new}"); do
    # check $file for user's access
  done
fi

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.

--Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20190612/7c698c39/attachment.html>