From: Stas Bekman <stas@stason.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: problem with not being able to enforce git content filters
Date: Tue, 16 Oct 2018 18:26:49 -0700 [thread overview]
Message-ID: <8660554f-9f48-af67-fbe2-f5aee5e61b09@stason.org> (raw)
In-Reply-To: <20181017005424.GH432229@genre.crustytoothpaste.net>
On 2018-10-16 05:54 PM, brian m. carlson wrote:
[...]
>> It doesn't help with direct commits to master, since CI would be
>> detecting it after it was committed. And when that happens we all know
>> that already because 'git pull' fails.
>
> Typically projects that have CI set up don't allow direct pushes to
> master, since that tends to allow to bypass CI, or they allow it only in
> exceptional circumstances (e.g., reverts). Also, typically most
> projects want to have some sort of review before code (resp. documents,
> other contributions) are merged. Most Git hosting platforms, including
> GitHub, offer protected branches, so it's something to consider.
>
> There is a possible alternative, and that's that if your project has
> some sort of build file (e.g., a Makefile), you can set it up to
> automatically insert hooks or git configuration into developers'
> systems, optionally only if it's in a Git repository. For example, you
> could add a pre-commit hook that fails if the filters are disabled.
>
> These are the approaches that tend to work well for most projects. I
> tend to prefer the CI approach with restricted branches because often I
> want to customize my hooks, but your project will decide what works best
> for it.
Yes, Brian, what you're sharing makes total sense when things are setup
this way, but this is not the case with the project I'm contributing to.
This one is setup, commit first, review later, due to having too few hands.
And I have already setup a CI to detect misconfigured systems. It'll
catch RPs in time, and everything else post-commit. Let's hope the
developers will watch the status of their commits and will react quickly
to fix their setup and mend the broken commit, when they see their
commit broke things. That's as good as it can get in this particular
situation I understand.
Thank you, Brian and Ævar for your support and very helpful suggestions.
--
________________________________________________
Stas Bekman <'))))>< <'))))><
https://stasosphere.com https://chestofbooks.com
https://experientialsexlab.com https://stason.org
https://stasosphere.com/experience-life/my-books
prev parent reply other threads:[~2018-10-17 1:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 20:36 problem with not being able to enforce git content filters Stas Bekman
2018-10-16 21:17 ` Ævar Arnfjörð Bjarmason
2018-10-16 22:12 ` Stas Bekman
2018-10-16 23:26 ` brian m. carlson
2018-10-16 23:48 ` Stas Bekman
2018-10-17 0:54 ` brian m. carlson
2018-10-17 1:26 ` Stas Bekman [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=8660554f-9f48-af67-fbe2-f5aee5e61b09@stason.org \
--to=stas@stason.org \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).