Top
Best
New

Posted by faithraven 1 day ago

Two Git ignore files nobody told me about(mihai.dinculescu.dev)
93 points | 63 comments
ktm5j 1 day ago|
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

infogulch 1 day ago||
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.
crtasm 1 day ago|||
Out of the box you can use ~/.config/git/ignore and ~/.config/git/config
ktm5j 1 day ago||
I have no ~/.config/git directory, ~/.config/git/config might take higher precedence, but ~/.gitconfig works too.
crtasm 1 day ago||
Yes you may have to create the directory :)
nom 1 day ago|||
you can add .gitignore to .gitignore ;)
ktm5j 1 day ago|||
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.
spider-mario 1 day ago||||
In fact tup does exactly that to the .gitignores it generates.
sinabis 1 day ago|||
yes, that works perfectly
moritzwarhier 1 day ago||
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

happymellon 1 day ago||
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 1 day ago|||
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.

6LLvveMx2koXfwn 1 day ago||
This is great, and nicely written up in the context of agentic repos etc, but presumably no-one reads the official docs, right: https://git-scm.com/docs/gitignore where the multiple ways of ignoring files are clearly stated?
faithraven 1 day ago||
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!

onaclov2000 1 day ago||
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 1 day ago||
The motivation fades to make things intuitive.
alexpotato 1 day ago|||
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"

bigfishrunning 1 day ago|||
So many people treat git commands like magic words, and then are terrified when they mess up their repo (example in this xkcd... https://xkcd.com/1597/)

Reading documentation is a superpower

faithraven 1 day ago|||
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 1 day ago||
Yeah, but Git is a tool, that in the face of an accident shoves you it's manual in the face.
coldpie 1 day ago|||
I'm definitely the friend in the alt-text of this comic. What do you mean you haven't read gitcore-tutorial(7)??
windward 1 day ago|||
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.
BeetleB 1 day ago|||
For a lot of tools, people usually read the docs once, and obscure stuff is quickly forgotten.
stephbook 1 day ago||
I have never seen these two files in any git repository I've cloned so far.
fortran77 1 day ago||
That’s because, unlike .gitignore, they are not committed.
psygn89 1 day ago||
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?
faithraven 1 day ago||
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: https://git-scm.com/docs/gitattributes#_filter
jo-m 1 day ago||
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.
BeetleB 1 day ago||
You missed this:

> Some configs don't allow extending

BigTTYGothGF 1 day ago||
> 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.

BerislavLopac 1 day ago||
> 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 1 day ago||
I can't believe that this article is still alive and well on the interwebz: MacGyver vs James Bond - https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...
TrianguloY 1 day ago||
I learned this while using IntelliJ, because it suggests both options. I searched for the difference and, once understood, I was able 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 1 day ago||
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.
dpkirchner 1 day ago|
See also: git check-ignore

You can use this subcommand to learn which ignore file is causing your files to be ignored.

https://git-scm.com/docs/git-check-ignore

faithraven 1 day ago|
That's a great shout. With more than one ignore file in play, this command is gold.
More comments...