Thread

Two Git ignore files nobody told me about

95 points · 65 comments · faithraven

Loading the complete thread in the background. This saved snapshot is available now. Refresh

DamonHD · 1790163858 · focus · HN ↗
Ah, very good!
festive-minsky · 1790163951 · focus · HN ↗
Thanks I had no idea about these either!
biglyburrito · 1790169453 · focus · HN ↗
I'd never heard of .git/info/exclude, core.excludesFile, or ~/.config/git/ignore before. Thanks for posting this!
6LLvveMx2koXfwn · 1790170419 · focus · HN ↗
This is great, and nicely written up in the context of agentic repos etc, but presumably no-one reads the official docs, right: <a href="https://git-scm.com/docs/gitignore" rel="nofollow">https://git-scm.com/docs/gitignore where the multiple ways of ignoring files are clearly stated?
1. alexpotato · 1790170736 · focus · HN ↗
  There is a tweet doing numbers on Twitter right now which is effectively:
  "Do the reading b/c you would be amazed how many people don't do the reading"
  1. bigfishrunning · 1790171025 · focus · HN ↗
    So many people treat git commands like magic words, and then are terrified when they mess up their repo (example in this xkcd... <a href="https://xkcd.com/1597/" rel="nofollow">https://xkcd.com/1597/)
    Reading documentation is a superpower
    faithraven · 1790171703 · focus · HN ↗
    I'd wager a small sum that git is the tool most of us learned by accident, some of them fortunate, some less so. Thankfully, this one was the former.
    1718627440 · 1790179812 · focus · HN ↗
    Yeah, but Git is a tool, that in the face of an accident shoves you it's manual in the face.
    coldpie · 1790176330 · focus · HN ↗
    I'm definitely the friend in the alt-text of this comic. What do you mean you haven't read gitcore-tutorial(7)??
  2. windward · 1790178389 · focus · HN ↗
    Do the reading b/c there's a machine that has done all the reading so it's hard to add value if you maintain the anti-intellectualism of 2010s software dev.
2. stephbook · 1790171562 · focus · HN ↗
  I have never seen these two files in any git repository I've cloned so far.
  1. fortran77 · 1790171846 · focus · HN ↗
    That’s because, unlike .gitignore, they are not committed.
3. faithraven · 1790171617 · focus · HN ↗
  Until Claude suggested .git/info/exclude, it never crossed my mind to question how ignoring worked. A search would have answered it in seconds, but you have to think to ask first. I didn't, and I suspect most people don't either. Especially with git, which nearly everyone learns by doing; very few of us ever sit down and learn it properly. That's why I wrote it up: so a few more people can learn this the way we learn everything else in git, by accident.
  Now that you mention it, I should add a link to those docs in the article. Thanks!
  1. onaclov2000 · 1790172558 · focus · HN ↗
    This is true, using AI to help discover better ways of working with stuff is pretty epic, reading docs are about as exciting as writing docs, esp when you are trying to get something done.
    gritzko · 1790177083 · focus · HN ↗
    The motivation fades to make things intuitive.
4. BeetleB · 1790177348 · focus · HN ↗
  For a lot of tools, people usually read the docs once, and obscure stuff is quickly forgotten.
ivyBadger920 · 1790171026 · focus · HN ↗
[dead]
psygn89 · 1790171495 · focus · HN ↗
This is great... one thing I wish is to be able to exclude are lines, for instance some lines in my config that only benefits the work I do. Some configs don't allow extending and that's where this would come in handy. Anyone have any tricks for that?
1. jo-m · 1790171920 · focus · HN ↗
  You can from the checked in config file include a local file which is not checked in (only if it exists).
  For example, with direnv, the `.envrc` in my projects usually has
  source_env_if_exists .envrc.local
  And the repo also ships with a `.envrc.local.example` file.
  1. BeetleB · 1790177530 · focus · HN ↗
    You missed this:
    > Some configs don't allow extending
2. faithraven · 1790172082 · focus · HN ↗
  You might be surprised, it's sort of possible. Ask your favourite AI agent about git clean filters, and .git/info/attributes, the per-clone sibling of .git/info/exclude. The docs are here: <a href="https://git-scm.com/docs/gitattributes#_filter" rel="nofollow">https://git-scm.com/docs/gitattributes#_filter
faithraven · 1790171586 · focus · HN ↗
[deleted]
dpkirchner · 1790172790 · focus · HN ↗
See also: git check-ignore
You can use this subcommand to learn which ignore file is causing your files to be ignored.
<a href="https://git-scm.com/docs/git-check-ignore" rel="nofollow">https://git-scm.com/docs/git-check-ignore
1. faithraven · 1790173758 · focus · HN ↗
  That's a great shout. With more than one ignore file in play, this command is gold.
globular-toast · 1790172931 · focus · HN ↗
Magit really is the only git frontend worth using. It exposes all of this kind of stuff in an easy to use way. You can easily ignore files using all three methods with magit.
The more useful thing here is the "typical use" of each one. People who don't know about other methods get this wrong a lot and put cruft from their own tools/editors in .gitignore which is annoying.
ktm5j · 1790173068 · focus · HN ↗
Just a nit-pick, but some/repo/path/.gitignore isn't necessarily committed to the repo. For example, if your repo has no .gitignore file, you can totally add one in your clone without adding it to the tree. Of course then you can't do something like `git add .` without committing it.
Also `~/.gitignore` works as a global gitignore. I usually stick something like `katie*` in there so I can copy some `script.sh` to `katie_script.sh` and then I can make changes that I don't want to commit.
Quick edit: I'm not sure `~/.gitignore` works out of the box.. looks like I stuck that in my `~/.gitconfig` for excludesfile
1. nom · 1790173444 · focus · HN ↗
  you can add .gitignore to .gitignore ;)
  1. ktm5j · 1790175241 · focus · HN ↗
    True! But a gotcha there is that if your repo does have a .gitignore in the tree then this trick won't work. I had a coworker try to do just that and we were all pretty confused when his changes kept getting committed. `git add ./` will stage changes to any file in the commit tree, even if that file matches a line in gitignore.
  2. spider-mario · 1790175615 · focus · HN ↗
    In fact tup does exactly that to the .gitignores it generates.
  3. [deleted] · 1790181477 · focus · HN ↗
    [deleted]
  4. sinabis · 1790184066 · focus · HN ↗
    yes, that works perfectly
2. crtasm · 1790173618 · focus · HN ↗
  Out of the box you can use ~/.config/git/ignore and ~/.config/git/config
  1. ktm5j · 1790174470 · focus · HN ↗
    I have no ~/.config/git directory, ~/.config/git/config might take higher precedence, but ~/.gitconfig works too.
    crtasm · 1790175228 · focus · HN ↗
    Yes you may have to create the directory :)
3. [deleted] · 1790174421 · focus · HN ↗
  [deleted]
4. infogulch · 1790174901 · focus · HN ↗
  I've been using $REPO/.scratch/ and .scratch/.gitignore with just `*` in it as a place for coding agents to use as temp storage (scripts, exports, plans, etc) that won't get committed. It's much easier to access these files under the repo path instead of wading through /tmp.
5. moritzwarhier · 1790185707 · focus · HN ↗
  Wait until you learn about
  .git/exclude --assume-unchanged --no-update-index
  .
  And fwiw, I think global/home-dir .gitignore is bad, for everything except of OS-level spam like .DS-Store
  1. happymellon · 1790193115 · focus · HN ↗
    Nah, I generate dependency trees from gradle because of the crappy way current $job has aggressive transient dependency scanning and I can't stand just updating someone else's transient dependency without validating that there isn't at least a new version of whatever pulled it in.
    I have dependency_tree globally excluded because it is my unique naming convention. Actually it might just be my unique approach because other people don't seem to mind having 1000 overrides for libraries they don't use.
    moritzwarhier · 1790194597 · focus · HN ↗
    [delayed]
    moritzwarhier · 1790197016 · focus · HN ↗
    Fair, and sorry, my tone was a bit off, I didn't think much when commenting.
    My preference of not having much in my global gitignore is only sensible for my particular daily work, if you need to partially track build folders in projects and can't control the ignore files automatically, a global ignore might make sense.
cxr · 1790173401 · focus · HN ↗
[dead]
1. quietbritishjim · 1790174417 · focus · HN ↗
  Or, you could have a build system that does a 100% out-of-tree build into ./build, and then if the build is broken you delete that one directory. You hardly need git to help you with that.
  1. cxr · 1790174778 · focus · HN ↗
    [delayed]
    quietbritishjim · 1790175762 · focus · HN ↗
    Get a new job? You can't be that "in charge of" a repo if you can't enforce rules this basic. In fact, I don't understand how you can enforce something as (being polite) unusual as banning .gitignore and yet can't enforce build system hygiene.
    cxr · 1790207159 · focus · HN ↗
    [delayed]
    askl · 1790175855 · focus · HN ↗
    > How do I get the people with bad hygiene that we're talking about to follow it?
    Same way you're currently getting them to not check in .gitignore files. Require them to write working build scripts.
  2. cxr · 1791136145 · focus · HN ↗
    [delayed]
2. Phemist · 1790174939 · focus · HN ↗
  So all your fellow devs do `ln -s contrib/gitignore ./git/info/exclude`?
  Also you can do `git status --ignored` and it will list all files changed, even if ignored. If that is really your main issue.
  1. cxr · 1790207521 · focus · HN ↗
    [delayed]
    Phemist · 1790222080 · focus · HN ↗
    The symlink creates what is effectively a version-controlled gitignore. It would be the obvious way of getting around your arbitrary restriction (and how do you know they are not doing this, the symlink is not checked in).
    My comment and the other replies show you how to use git to check and clean the files of the much maligned horked build script. These will work regardless of the gitignore contents.
    But then again, pretty sure you are just having a laugh at our expense by taking this ridiculous position.
    cxr · 1790341794 · focus · HN ↗
    > The symlink creates what is effectively a version-controlled gitignore
    No, it doesn't. The ln(1) invocation you wrote is not going to work. As written, it contains two glaring errors obvious on sight to anyone who actually has enough experience with the particulars symlinks and Git's .git/info/exclude.
    > My comment and the other replies show you how to use git
    Oh, gee, thanks!
    Phemist · 1790344710 · focus · HN ↗
    Yeah I guess there are things to nitpick about the ln. And ofc the comments are more for onlookers, to contextualize the poor decision making shown in banning .gitignore suggested by the original post. Obviously this is some emotional topic for you, seeing all the snarky and defensive responses, so I will leave it at that.
    cxr · 1790345208 · focus · HN ↗
    [delayed]
3. athorax · 1790175076 · focus · HN ↗
  This is one of the strangest opinions I've seen in awhile. Your complaint seems like it should be pointed at projects not having a working "clean" make target.
  Also:
  git status --ignored git clean -ndX # preview what would be removed git clean -fdX # actually delete the files (warning: destructive)
  1. cxr · 1790207710 · focus · HN ↗
    [delayed]
  2. cxr · 1790343059 · focus · HN ↗
    [delayed]
4. Supermancho · 1790179080 · focus · HN ↗
  I would not recommend this setup, which is effectively using a more complicated and error prone system. That being said, I could handle it.
grimgrin · 1790173722 · focus · HN ↗
this was probably discovered by many when seeking how to globally ignore agent configs, until perhaps they decided they'd like to start committing agent configs
henrydoughty · 1790173989 · focus · HN ↗
On Windows I never found ~/.config/git/ignore. I just used .gitignore for everything.
I've been leaving notes sitting untracked rather than put a filename only I use into the repo. .git/info/exclude is what I actually needed.
markbnj · 1790175348 · focus · HN ↗
Very useful. Minor typo in the post if you're adding the claude code flag: it's "respectGitIgnore" not "respectGitignore". [probably not true, see below]
1. faithraven · 1790175501 · focus · HN ↗
  Thanks, but I think it's the other way round. The docs, the published JSON schema and the binary itself all spell it respectGitignore, lowercase i, named after the .gitignore file. <a href="https://code.claude.com/docs/en/settings-reference#respectgitignore" rel="nofollow">https://code.claude.com/docs/en/settings-reference#respectgi...
  1. gritzko · 1790177209 · focus · HN ↗
    The git-ness of this argument exceeds 100%.
  2. markbnj · 1790177710 · focus · HN ↗
    When I first added it as "respectGitignore" it had no effect and my ignored folder did not show in the @ list. I changed it to "respectGitIgnore" and saved settings.json and the folder did show in the @ list. Then, after a claude restart, the folder stopped showing up. I edited and saved settings.json (but maintained the spelling "respectGitIgnore" and the folder started showing up again. Then after a coding session it stopped showing up, and changing the case of the 'i' and saving hasn't restored the behavior I want... so it just seems flaky at this point.
havnagiggle · 1790175758 · focus · HN ↗
I prefer a presubmit check for DO NOT SUBMIT. And then I have those floating around as needed.
1. etatester · 1790176019 · focus · HN ↗
  What footguns? I disable most git hooks so your solution still has ways to shoot your feet.
  1. havnagiggle · 1790176996 · focus · HN ↗
    Mostly the spooky action at a distance. Gitignore expressions and inheritance of the ignore expressions can exclude files you actually need to include, and you basically lose sight of those -- admittedly those are probably safer bugs than including things that shouldn't be included. But if a file (or even specific lines) shouldn't be included, I would prefer the file/lines have a marker that says it shouldn't be included.
    I run the same presubmits on pre-receive and merge requests, so you wouldn't get too far shooting your own foot.
n4bz0r · 1790176454 · focus · HN ↗
I absolutely despise when people commit their personal ignore patterns. My opinion is that the code in the repository shouldn't know anything about personal environments. The exception is when the entire team benefits from having their common ignore patterns in the repo - in this scenario, the environment details are no longer personal and it doesn't make much sense to not commit them. In any other situation, people are perfectly capable of ignoring their crap on their own and shouldn't pollute the repo. Glad .git/info/exclude is getting more exposure.
1. BeetleB · 1790177484 · focus · HN ↗
  > I absolutely despise when people commit their personal ignore patterns.
  Beyond things not being neatly compartmentalized, what is the problem? The only risk I see is that you'll have a file you forgot to commit because it happened to match one of those patterns.
  Having strong opinions on stuff like this is not healthy.
2. OutOfHere · 1790186837 · focus · HN ↗
  It depends on whether the pattern is general enough to potentially be useful for others. If it is, then by all means add it to .gitignore. If on the other hand it's specific to the user, e.g. '2026_report.docx', then no, it should not be added.
tonymet · 1790177158 · focus · HN ↗
Does anyone have a trick to blacklist files by type e.g. object / binary code, gz files. Often objects & commands lack extensions so going by extension doesn’t work. Git seems to guess binary pretty well upon diff, how to tap into that.
I’ve used pre-commit hooks for this but I’d rather a simple config flag, it seems trivial.
BigTTYGothGF · 1790177309 · focus · HN ↗
> but pushing the silly filename I picked for my private notes to a remote repository feels unclean
Pick a directory for them and ignore the directory. Other team members who want to keep their own notes can use that directory as well.
TrianguloY · 1790181214 · focus · HN ↗
I learned this while using IntelliJ, because it suggests both options. I searched for the difference, and once understood in and to use the knowledge everywhere.
The other useful advice is when there is a full folder you want to ignore. Putting a .gitignore with a single "*" ignores the full folder...including the gitignore file itself.
I do use it when I quickly need to ignore the .idea folder
teekert · 1790181980 · focus · HN ↗
Oh this is nice. I've fallen into the habit of ignoring /devtools and put any input for agents there,I mount it in the agent container and have it put it's auth and memory there, and plans. And a "start agent container"-script, because people have their own preferences when it comes to agents.
BerislavLopac · 1790194673 · focus · HN ↗
> editor clutter has no business in any project's .gitignore, and yet there it is, in most of them
I couldn't agree more with this - except that, in practice, nobody bothers to add their own environment clutter to their own global (or even project-related) gitignore. So invariably we end up with PRs (and even main :scream:) peppered with various .vscode and similar lost souls.
BerislavLopac · 1790194807 · focus · HN ↗
I can't believe that this article is still alive and well on the interwebz: MacGyver vs James bond - <a href="https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/" rel="nofollow">https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.