Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Antoine Queru <Antoine.Queru@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx ? > ... >> +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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html