Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 6, 2016, 16:13 UTC
Message-ID: <xmqq7fe2z45p.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <vpq37oqjqgn.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 21 quoted lines

> Antoine Queru <Antoine.Queru@grenoble-inp.org> writes:
>
>> Currently, a user wanting to prevent accidental pushes to the wrong
>> remote has to create a pre-push hook.  The feature
>
> It's not clear what "The feature" refers to. Given the context, I read
> it as "pre-push hook", but I think this is not what you meant.
>
>> User, password and port are not treated. Should it be ?
>
> Please elaborate on "not treated". What happens if github.com is
> blacklisted by the user pushes to http://me@github.com ?
> ...
>> +remote.pushBlacklist::
>> +	The list of remotes the user is forbidden to push to.
>> +	See linkgit:git-push[1]
>
> This is only true when remote.pushDefaultPolicy is "allow". It makes
> sense to say it explicitly here, if only to have a pointer to
> pushDefaultPolicy.
> ...

All good comments and suggestions, but I am bothered a lot more by this being called "Policy" and uses words like "Prevent" and "Forbidden" as if there is a real enforcement mechanism, when in reality what is proposed is only advisory.

It is a good design balance to leave such a client-side mechanism advisory and go no further than that; a truly draconian client side mechanism has no value, as the Git protocol is open, well documented and you can write and use a more liberal client to work around such a mechanism. I do not think selling such an advisory mechanism as if it is a policy enforcement feature.

"user wanting to avoid accidental pushes" the log message mentions sets the expectation at the right level, I would think. I do not think this is about a "Policy enforcement"; where its value lies in is accident prevention (and possibly self discipline enforcement).