find . -name '.DS_Store' -deleteUltimately, it's the responsibility of each developer to determine whether or not the files they've added to their local clone really belong in source control! I've never encountered this issue, either, and I think I'd be unhappy working on a team where it was a serious problem.
That said, the whitelist approach does seem kinda interesting. It's really what should be present from the start, since Git had a manual staging process. But maybe this gap highlights a legit usabiiity issue. Maybe "add everything" plus an explicit, version-controlled whitelist is somehow easier or more intuitive than the "add nothing" default.
--
To me the normal approach makes equal sense. I create a file, but I'm not ready for other people to see it yet, because it's just a placeholder. So I don't add it. But another set of files are ready, and are part of one logical step of the change, so I add them specifically and commit.
Excluding things like .vscode and .DS_store, which is a common and universal "don't need that in my repo", is a trivial way to reduce the burden for everyone (the goal of software, imo), maintainer included.
I’m old and cranky enough to want to believe that excluding contributions from VS Code and macOS users is a trivial way to reduce the maintainer’s burden and improve software quality.
That’s completely unfair, of course, and probably false too.
edit: s/maybe/probably/
Now, if you don't want contributors, or at least novice contributors that don't know to proofread their commits or ignore their own IDE files, then this actually helps you screen out the contributors you don't want to engage with early.
https://git-scm.com/docs/git-config#Documentation/git-config...
Don't accept people playing with shotgun commits; there, problem(s) solved.
chef's kiss This is replacing one of the memes on my whiteboard rn
(git config --global core.excludesfile "$CONFIG/git/ignore")
.gitignore is committed to the repository and should be for files created by the repository that shouldn't appear in 'git status' like build/, etc.
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. [...]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 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?")
While I don't think we've ever merged a pr with ide files, we do merge the .gitignore part when people put them in their commits which has lead to growth over time...
One way of thinking about this is to note that there are an awful lot of these tools, and so each person should look after their own shit rather than fucking it up for everybody else. Another is to note that the number of these tools is finite, and team members won't be using all of them, and so over time the centralized ignore file will tend towards a useful degree of completeness.
.*/
They decided to waste the default warning with a wrist-slap for using "master"
I think that one can eliminate that by adding this to /etc/gitconfig, ~/.config/git/config or ~/.gitconfig as appropriate:
[init]
defaultBranch = master $ git init
hint: whoa whoa whoa my dude "master" no...
$ git config --global init.defaultBranch aids_is_gods_punishment_for_depravity
$ git init
okPuts the onus on the committer
> Luckily, you realize that you can turn the blacklist of files (the gitignore) into a whitelist, by just ignoring everything and manually un-ignoring desired files.
this will not work and tbh it's fitting a square peg in a round hole. it technically might fit if you shave off the square enough but large repos don't do this, they use a round peg: https://github.com/github/gitignore
I did think the blacklist for this purpose was a bad idea anyways, before I saw this, so I used whitelist anyways already. (However, you can use which way you prefer, in case you do not like this, either.)
So, even of you explicitly add a directory, any files or directories starting with a dot inside it gets skipped.
Of course there is .git/info/exclude, but I'm not sure it's working an already cached (present on remote) files. This is another common use case git handles badly - local changelist. For example having .env file on remote with variable names only to denote structure and filling those out in local without showing these modifications in staging.
In the very first line of the description on https://git-scm.com/docs/gitignore it states "A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details."
This is a core behavior of git that has existed since creation. The gitignore is really only there to keep git status tidy and let people blindly use git add -A. Once a file is added to a repo it is never ignored until it is removed. This is why you should should rename your example .env to .env.example.
I don't use .gitignore files in projects that I control. A few times I've been tripped up by these things ignoring something that should not have been.
I feel that these files should stay local. I don't want your .gitignore any more than I want your .vimrc or whatever. If you maintain a very messy local repo with lots of extraneous files, and find that this file helps you when you're using git, by all means create one for yourself.
davydm•6mo ago
I highly suggest using templates from https://github.com/github/gitignore for your project as they tend to include a lot of files commonly found in them - eg .idea folders and so on.
RGBCube•6mo ago
You should just pick the nearly exhaustive option instead
FrenchyJiby•6mo ago
For per-user gitignore, one can set the following config in ~/.gitconfig:
Then your file at ~/.config/git/gitignore can be a normal format, and not need to be stored in repo. Perfect for system files (.DS_Store...) or editor swap files etc.tonymet•6mo ago
Baarsgaard•6mo ago