git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: problem with not being able to enforce git content filters

From
SBStas Bekman <stas@stason.org>
Date
Oct 17, 2018, 01:26 UTC
Message-ID
<8660554f-9f48-af67-fbe2-f5aee5e61b09@stason.org>
In-Reply-To
<20181017005424.GH432229@genre.crustytoothpaste.net>

On 2018-10-16 05:54 PM, brian m. carlson wrote: [...]

Show 21 quoted lines
>> 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
Previous: brian m. carlson
Message 7 of 7 in “problem with not being able to enforce git content filters”
  1. Stas BekmanOct 16, 2018
  2. Ævar Arnfjörð BjarmasonOct 16, 2018
  3. Stas BekmanOct 16, 2018
  4. brian m. carlsonOct 16, 2018
  5. Stas BekmanOct 16, 2018
  6. brian m. carlsonOct 17, 2018
  7. Stas BekmanOct 17, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.