From: Aaron Schrab <aaron@schrab.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Lars Schneider <larsxschneider@gmail.com>,
Francois Beutin <beutinf@ensimag.grenoble-inp.fr>,
"Randall S. Becker" <rsbecker@nexbridge.com>,
git@vger.kernel.org,
simon rabourg <simon.rabourg@ensimag.grenoble-inp.fr>,
wiliam duclot <wiliam.duclot@ensimag.grenoble-inp.fr>,
antoine queru <antoine.queru@ensimag.grenoble-inp.fr>
Subject: Re: [Opinion gathering] Git remote whitelist/blacklist
Date: Tue, 24 May 2016 18:24:51 -0400 [thread overview]
Message-ID: <20160524222451.GA23162@pug> (raw)
In-Reply-To: <vpq37p74nu1.fsf@anie.imag.fr>
At 14:55 +0200 24 May 2016, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>So, when trying a forbidden push, Git would deny it and the only way to
>force the push would be to remove the blacklist from the config, right?
>
>Probably the sanest way to go. I thought about adding a "git push
>--force-even-if-in-blacklist" or so, but I don't think the feature
>deserves one specific option (hence add some noise in `git push -h`).
It might make sense to bypass the blacklist checking if the existing
--no-verify is used. In the past I've used a pre-push hook to implement
a similar method of preventing accidental pushes, and found that to be a
good way to skip the checking when I wanted to override the check for a
specific push. The builtin blacklist checking could be seen as another
type of verification. The downside to that would be that if the
blacklist was used along with a pre-push hook for different types of
checks users would likely only be able to see the error message from one
of them; but that could also apply to a pre-push hook that implements
different types of checks and short circuits at the first failure.
prev parent reply other threads:[~2016-05-24 22:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1040142021.5607762.1463753271105.JavaMail.zimbra@ensimag.grenoble-inp.fr>
2016-05-20 14:21 ` [Opinion gathering] Git remote whitelist/blacklist Francois Beutin
2016-05-20 14:22 ` Randall S. Becker
2016-05-23 12:51 ` Francois Beutin
2016-05-24 10:12 ` Francois Beutin
2016-05-24 10:55 ` Lars Schneider
2016-05-24 12:55 ` Matthieu Moy
2016-05-24 16:07 ` Junio C Hamano
2016-05-24 16:16 ` Randall S. Becker
2016-05-24 16:20 ` Junio C Hamano
2016-05-24 19:25 ` Lars Schneider
2016-05-24 21:02 ` Randall S. Becker
2016-05-24 19:11 ` Lars Schneider
2016-05-24 19:22 ` Matthieu Moy
2016-05-25 22:52 ` Jeff King
2016-05-24 22:24 ` Aaron Schrab [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160524222451.GA23162@pug \
--to=aaron@schrab.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=antoine.queru@ensimag.grenoble-inp.fr \
--cc=beutinf@ensimag.grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
--cc=rsbecker@nexbridge.com \
--cc=simon.rabourg@ensimag.grenoble-inp.fr \
--cc=wiliam.duclot@ensimag.grenoble-inp.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.