[ofiwg] linux coding style question, or what is the libfabric interpretation of "resembles"

[Patrick MacArthur]

On 03/11/2015 10:47 AM, Blocksome, Michael wrote:
> 
>> 
>> On Mar 10, 2015, at 4:08 PM, Patrick MacArthur
>> <pmacarth at iol.unh.edu> wrote:
>>> FWIW in UNH EXS, I added code to the autogen.sh script which
>>> copies the pre-commit hook script into place (which itself lives
>>> in the UNH EXS git repository).  This isn't foolproof, but means
>>> that most users will get the hook automatically when they first
>>> attempt to build a fresh clone.
>> 
>> What do you do if the user already has a pre-commit hook in place?
>> Do you fail, complain loudly, install the script in such a way that
>> it chains, or something else?  Clobbering an existing user script
>> wouldn't be very friendly.
>> 
>> -Dave
> 
> And what if there are multiple remotes in the git repository .. does
> the pre-commit hook run for all of them? And if someone clones your
> clone of the top level ofi git repository? How about a git repository
> created with git-init and then later the ofi remote is added with
> git-remote?

Hooks are per-repository but completely independent of remotes, and the
pre-commit hook (in my mind) shouldn't be affected at all by remotes.  I
was thinking that the "blessed" hook scripts would just be held in the
"config" directory of the project, so the pristine copies of the hooks
would just be part of the repository like anything else.  When
autogen.sh is run to generate configure, etc., the hook script would
then get installed into the correct directory.

> These pre-commit hooks are inherently out of your control as they are
> specific to each distributed git repository. We could offer help in
> setting up the pre-commit hooks for the convenience of the developer,
> but eventually all of the heavy lifting has to be done on the server
> - either as a pre-receive hook or some other kind of check on pull
> requests.

Agreed.  Installing a pre-commit hook just lets the developer know that
something is wrong with their commit before it gets pushed.  The
developer can always remove/alter the hook himself.  We will still need
a hook on the github side if we wish to do the same verification on all
pull requests.

> I agree that clobbering existing local hooks is not very nice. And,
> IMHO, a manual step to set up this convenience isn't unreasonable.

The solution for this as I see it: put a magic comment at the top of our
"blessed" pre-commit hook.  If there is no existing pre-commit hook or
if it contains the magic comment, replace it with ours (so that it is
always up-to-date).  Otherwise, if there is a pre-commit hook that lacks
the magic comment, then the user put his own pre-commit hook, and we
won't touch it (we may print a message indicating that we did not
install the "blessed" pre-commit hook).

If the group likes the manual solution better, I'm ok with that as well.
 I just wanted to point out that we do have a mechanism to install hooks
into a repository semi-automatically, should we wish to do so.

-- 
Patrick MacArthur <pmacarth at iol.unh.edu>
Research and Development, High Performance Networking and Storage
UNH InterOperability Laboratory