yencabulator on .gitignore Is Inherently Sisyphean

Comment on .gitignore Is Inherently Sisyphean

This is a bad idea and if this seems necessary you are interacting with very low quality committers. People who don't even bother reading their own commits do not deserve to get their commits merged.

Also, that gitignore doesn't even work. man gitignore:

       •   An optional prefix "!" which negates the pattern; any
           matching file excluded by a previous pattern will become
           included again. It is not possible to re-include a file
           if a parent directory of that file is excluded. Git
           doesn’t list excluded directories for performance
           reasons, so any patterns on contained files have no
           effect, no matter where they are defined. [...]

cstrahan 1y

Also, that gitignore doesn't even work.

It's not terribly far off. This works:

  diff --git a/.gitignore b/.gitignore.new
  index 7dc7aea..fc9ebfe 100644
  --- a/.gitignore
  +++ b/.gitignore.new
  @@ -3,17 +3,21 @@
   !.gitignore
   
   # whitelist `src` directories and their children, regardless of place
  +!src
   !src/**/
   !src/**/*.rs
   !Cargo.{toml,lock}
   
   # whitelist root `pysrc` directory
  +!/pysrc
   !/pysrc/*.py
   !pyproject.toml
   !poetry.lock
   
  +!/cmd
   !/cmd/*.go
   !main.go
   !go.{mod,sum}
   
  +!/docs
   !/docs/*.md

This is how I've been managing my dotfiles for over a decade (https://github.com/cstrahan/dotfiles/blob/master/.gitignore).

This is the email thread I started back on 2016/03/3 to pin down the gitignore behavior that we now have today (there was a regression between git version 2.6.0 and 2.7.0):

https://lore.kernel.org/git/1457057516.1962831.539160698.3C8...

(For posterity: the subject line was "Change in .gitignore handling: intended or bug?")

Comments