7 ms·

.gitignore Isn't the only way to ignore files in Git

600 points by FergusArgyll 4mo ago

bitvvip 4mo ago
I still like using gitignore very much
Hendrikto 4mo ago
This is just a very low-effort regurgitation of this: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore
- jagged-chisel 4mo ago
  Hey, come on now - they added 'check-ignore' which is good complementary advice.
- _the_inflator 4mo ago
  You made my day. Everything is said and explained there. Ok, sometimes a more vivid and visually explanatory style would help, but here still Google is your friend for individual concepts. One of the best resources there is. git is a hell of a tool. It looks simple but is so beautifully versatile without being complex or not deductive.
  - y2244 4mo ago
    "Google is your friend for individual concepts." Asking aLlm is the new google
  - b40d-48b2-979e 4mo ago
    git is a hell of a tool. It looks simple but is so beautifully versatile without being complex without being complex Uh, what?
    - rafram 4mo ago
      What part of Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 10 threads Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.43 KiB | 1.43 MiB/s, done. Total 8 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (7/7), completed with 7 local objects. don't you understand?!
      - onraglanroad 4mo ago
        Well, since I know what a delta is, and I know what an object is, I understand all of it.
        rafram 4mo ago
        Congratulations!
        onraglanroad 4mo ago
        Learn what those two things are and you can join me in celebration!
        rafram 4mo ago
        This is an absolutely obnoxious and unproductive mindset.
      - dofm 4mo ago
        One of the things I find funniest about git is that it is so exasperating that there is a comedy tool that generates fake git man pages that are worryingly convincing. https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ And each time someone quotes one there is a chance that an LLM will be trained on it.
        Intermernet 4mo ago
- axus 4mo ago
  Submit that link to Hacker News, and see how far it gets!
bryancoxwell 4mo ago
I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.
- RSHEPP 4mo ago
  Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
  - junon 4mo ago
    Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.
    - bryancoxwell 4mo ago
      Yeah this is pretty much it.
    - tomjakubowski 4mo ago
      I use git worktrees pretty heavily in my own workflows (I worked like an AI agent before AI agents made worktrees cool). I like to track my ephemera/utility scripts in git, so what I do is keep a private ephemera repo for those, and then use `git worktree add` from the collaborative repo to check out the branch I'm working on there into a subdirectory of my ephemera repo. git-home/ company-project/ <-- git repo with main checked out ephemera/ <-- my private repo my-data-script.py work/ <-- gitignored company-project-feature-X/ <-- worktree on feature-X branch company-project-feature-Y/ <-- worktree on feature-Y branch This way, too, I can easily use the same ephemera scripts across multiple branches, or even multiple repos, concurrently.
      - junon 4mo ago
hk1337 4mo ago
~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO. my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things. the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.
- b40d-48b2-979e 4mo ago
  As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
  - hk1337 4mo ago
    Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.
  - mroche 4mo ago
    You may need to have certain directories be excluded depending on the programs you use. For example, the default Chrome profile location is within ~/.config, which includes cache data that can be multiple gigabytes in size.
    - b40d-48b2-979e 4mo ago
      Ouch. It doesn't respect `$XDG_CACHE_HOME`?
      - mroche 4mo ago
        Browsers are some of the most annoyingly configured applications out there.
    - Ferret7446 4mo ago
      That's what .gitignore is for ;)
judofyr 4mo ago
Not sure where I picked up this, but I’ve added this to my global Git ignore: attic That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.
- williamjackson 4mo ago
  I do this too! But I call it `.local`
  - zahlman 4mo ago
    I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.
  - bflesch 4mo ago
    Doesn't git automatically exclude all files starting with a dot?
    - micael_dias 4mo ago
      No
    - groundcontr01 4mo ago
      Hey do you have a GitHub I can look at?
      - bflesch 4mo ago
        I have nothing of value ;D
- weinzierl 4mo ago
  Mine is aux and I hide it by putting a .gitignore in it that just contains am asterisk (*), nothing else, that way it ignores itself and anything in it.
jeremyscanvic 4mo ago
I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!
barbazoo 4mo ago
Exclude sounds like a recipe for sadness.
wpollock 4mo ago
One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory). Machine-wide configuration is called "system" in git, and generally lives under "/etc".
globular-toast 4mo ago
Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).
- juxtapose 4mo ago
  Magit introduced me to them in the first place. :-D
uptown 4mo ago
Not really news. I worked with dozens of developers who have managed to ignore files in Git.
kevincox 4mo ago
The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet. My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.
- wccrawford 4mo ago
  I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain. In the future, I think I might just be less nice about it. I dunno.
  - eyelidlessness 4mo ago
    I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake. It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context. Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.
  - nomel 4mo ago
    Yeap. To reduce pain, you need to work with reality rather than ideals. If you work with a big group, you either add a few lines into your gitignore, or you write code to check for those very same files in your CI/PR system, because you're tired of reversing commits and rejecting PRs because you're the only one that cares about a few extra files.
dofm 4mo ago
Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
- tremon 4mo ago
  That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?
  - deleted 4mo ago
    [deleted]
  - deleted 4mo ago
    [deleted]
  - dofm 4mo ago
    I mean sure, if you're this worried about ten bytes and prefer instead to spend time endlessly lecturing new Mac-based submitters about the additional overhead of supporting Mac-based submitters.
    - saagarjha 4mo ago
      As a Mac user, you should tell them how to do a better job.
      - dofm 4mo ago
        This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of https://en.wikipedia.org/wiki/Narcissism_of_small_differences https://en.wikipedia.org/wiki/Narcissism_of_small_difference... Me, I am pragmatic. I have set this in my local config and I've added it to my repos to be certain. Because it's ten bytes.
tonymet 4mo ago
these are great for ignoring files by name, but you often want to ignore binary files or other files by type. Set a global hooks dir, and then block binary files in pre-commit by using file or checking the git index git config --global core.hooksPath ~/.config/git/hooks Or block large changes, because binary mods are often larger than a real diff.
PunchyHamster 4mo ago
another useful snippet [includeIf "hasconfig:remote.*.url:git@git.company.com:*/**"] path = /home/dir/per/company/config allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo config works for dir too [includeIf "gitdir:/home/user/src/work1/"] Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash
hmokiguess 4mo ago
git is so incredible, it never ceases to amaze me, what a timeless piece of software
lmf4lol 4mo ago
Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore ! I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me… And Today, it got s little bit better :-)
hungryhobbit 4mo ago
Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`. This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file). With `.gitattributes` in the root of your project, you can just add a line: `package-lock.json -diff` Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.
- clates 4mo ago
  > that is pure noise from a Git standpoint It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.
  - po1nt 4mo ago
    It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.
    - gpvos 4mo ago
      DX = ? Developer experience maybe?
      - sisve 4mo ago
        Yes
    - nine_k 4mo ago
      The point is that it should not be massive.
codymisc 4mo ago
[flagged]
leleat 4mo ago
There is also git update-index --[no]-skip-worktree for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.
- oezi 4mo ago
  This is what I use for making changes to local settings.json. Works nicely.
elyobo 4mo ago
Relatedly, some aliases I have in place. assume = update-index --assume-unchanged unassume = update-index --no-assume-unchanged assumed = "!git ls-files -v | grep ^h | cut -c 3-" unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged" assumeall = "!git st -s | awk {'print $2'} | xargs git assume"
arikrahman 4mo ago
[dead]
andrelaszlo 4mo ago
Here's how I use the excludes file to set a different config for a project directory containing multiple repos: https://laszlo.nu/blog/project-level-git-config.html https://laszlo.nu/blog/project-level-git-config.html
- sgc 4mo ago
  I *literally* cannot read that yellow text on the white background. I even tried changing the brightness to almost 0, but there is just not enough contrast.
  - andrelaszlo 4mo ago
    Oh no, I forgot to test light mode. Thanks for letting me know! I'll fix it as soon as I'm in front of a computer. Happy Midsummer!
  - andrelaszlo 4mo ago
    Fixed now, thanks again for your feedback!
antisol 4mo ago
Point of pedantry: > The ignore file lives in your machine’s home directory in ~/.config/git/ignore. Whatever filenames are added to this file are ignored globally at a machine-level. The wording here is slightly wrong: ~/.config/git/ignore will ignore files per-user on the machine, not "at a machine level". And it's not "your machine's home directory", it's your user's home directory on that machine. Any other users on the same machine will not see this. Git calls this "global", as in "global for the user". Git config does also have a --system option which modifies the system-level config file, /etc/gitignore. You could probably ignore stuff at the system/machine level (hint: you don't want to), with this. I'd do something like: $ sudo git config --system core.excludesFile /etc/gitignore $ sudo touch /etc/gitignore Note however that user config will override this, so any user who has a core.excludesFile setting will not also look at your system level excludes file. Which is a pretty big caveat.
- smw 4mo ago
  Why would you expect something in your home directory to affect other users?
  - antisol 4mo ago
    Why would you ask me that? I'm not the one who called it "your machine's home directory"
supermdguy 4mo ago
One trick I’ve used is creating a folder and then adding a .gitignore inside it with *. Then nothing in that folder gets tracked, without needing to add anything to the public gitignore. Didn’t know about .git/config though!
- linhns 4mo ago
  Yeah it's in the document but there are no examples on it.
dalton_zk 4mo ago
Nice, I didn't know the other options besides .gitignore
yieldcrv 4mo ago
but dont forget dockerignore if you use docker
h4kunamata 4mo ago
>~/.config/git/ignore This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels. I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.
- atomicnumber3 4mo ago
  Idk, I can imagine a specific weird usecase. I use IntelliJ. My coworkers don't. They don't want my .idea folder in git. (You're probably thinking "ok, yep, gitignore!" And you're right except my boss ideologically does not want any *hint* of what IDE you use in the repo. Including in the gitignore. So each person putting .vscode or .idea in their local config's ignore actually makes sense. (Relative to the nonsensical parent requirement... of course).
- Ferret7446 4mo ago
  That sounds like a you problem for not syncing your dotfiles across devices
adamgordonbell 4mo ago
you may have a personal notes.txt file in a repository that you don’t want to check into git but you also don’t want to add to .gitignore because it’s unique to your workflow. The exclude file lives in the .git directory of every Git repository but changes to it are not checked into Git Wtf. I've always wanted this, and it was right there.
- benrutter 4mo ago
  > Wtf. I've always wanted this, and it was right there. Haha, same! I was literally looking for this feature last week without realising. What could be more git- the problem is rarely that it can't do something, but the ergonomics of discovering how to make it work correctly.
nonoesp 4mo ago
git update-index --assume-unchanged path/to/file https://git-scm.com/docs/git-update-index https://git-scm.com/docs/git-update-index
stevage 4mo ago
Wow, how did I not know about the exclude file? I've had this need so many times - working on a shared repo where I want to ignore some files locally.
rmunn 4mo ago
I have a habit of writing myself notes in various .txt files, and then not cleaning them up often enough so they end up cluttering my `git status` view. I ended up with a solution not mentioned in the article: create a `scratch` directory, and a `scratch/.gitignore` file containing just one line: `*`. This makes Git ignore everything in the scratch directory, including that same .gitignore file — so I never accidentally check it into Git, and don't end up pushing my personal .gitignore settings onto my coworkers. Of course, I could have used .git/info/exclude for that, and not risked accidentally adding my `scratch` directory with `git add -A` or something. So I (re-)learned something (which I'd known about but forgotten) today. But as a reminder to anyone else who had forgotten this: .gitignore files are processed throughout the repo, not just at the top level. You can sprinkle them throughout the repo structure for finer-grained control, which may come in handy in some circumstances.
- ivan888 4mo ago
  There's also the global gitignore configuration (core.excludesfile=~/.gitignore_global), which for me contains things like: *.swp, .DS_Store, scratch, etc.
rlpb 4mo ago
Placing various artifacts (eg. build artifacts) inside the source tree always seemed like a historical mistake to me. It leads to various accidents such as people checking in their credentials and accidentally bundling such files in source distributions, for example. These consequences are real. Debian build tooling places build artifacts in the parent directory on the assumption that this is acceptable, but it then surprises people since it's not the norm anywhere else. Perhaps this ship has sailed. But I think it's worth pointing out that if you have an option, don't design things that place things inside the source tree if you can avoid it.
ramijames 4mo ago
I love these types of threads the most. I learn so much.
shinobi-apps 4mo ago
[flagged]
codensolder 4mo ago
something new i learned today, thanks!
maxlin 4mo ago
My first and hopefully only clash with the global ignore file was debugging why a project worked differently between machines. There was a global ignore on the machine I was working on (that I didn't place) that "smartly" tried to exclude "irrelevant" code / project files regardless of project. I see version control somewhat similarly as I see traffic laws. Sure, they could work in entirely different ways, Germans like their autobahns, but breaks to the norm in an otherwise planar field are rarely arguable for.
pacman1337 4mo ago
another way is to use shortcuts
p1024k 4mo ago
[dead]

600 points by FergusArgyll 4mo ago

I still like using gitignore very much

This is just a very low-effort regurgitation of this: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore

jagged-chisel 4mo ago
Hey, come on now - they added 'check-ignore' which is good complementary advice.
_the_inflator 4mo ago
You made my day. Everything is said and explained there. Ok, sometimes a more vivid and visually explanatory style would help, but here still Google is your friend for individual concepts. One of the best resources there is. git is a hell of a tool. It looks simple but is so beautifully versatile without being complex or not deductive.
- y2244 4mo ago
  "Google is your friend for individual concepts." Asking aLlm is the new google
- b40d-48b2-979e 4mo ago
  git is a hell of a tool. It looks simple but is so beautifully versatile without being complex without being complex Uh, what?
  - rafram 4mo ago
    What part of Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 10 threads Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.43 KiB | 1.43 MiB/s, done. Total 8 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (7/7), completed with 7 local objects. don't you understand?!
    - onraglanroad 4mo ago
      Well, since I know what a delta is, and I know what an object is, I understand all of it.
      - rafram 4mo ago
        Congratulations!
        onraglanroad 4mo ago
        Learn what those two things are and you can join me in celebration!
        rafram 4mo ago
        This is an absolutely obnoxious and unproductive mindset.
    - dofm 4mo ago
      One of the things I find funniest about git is that it is so exasperating that there is a comedy tool that generates fake git man pages that are worryingly convincing. https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ And each time someone quotes one there is a chance that an LLM will be trained on it.
      - Intermernet 4mo ago
axus 4mo ago
Submit that link to Hacker News, and see how far it gets!

bryancoxwell 4mo ago

I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.

RSHEPP 4mo ago
Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
- junon 4mo ago
  Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.
  - bryancoxwell 4mo ago
    Yeah this is pretty much it.
  - tomjakubowski 4mo ago
    I use git worktrees pretty heavily in my own workflows (I worked like an AI agent before AI agents made worktrees cool). I like to track my ephemera/utility scripts in git, so what I do is keep a private ephemera repo for those, and then use `git worktree add` from the collaborative repo to check out the branch I'm working on there into a subdirectory of my ephemera repo. git-home/ company-project/ <-- git repo with main checked out ephemera/ <-- my private repo my-data-script.py work/ <-- gitignored company-project-feature-X/ <-- worktree on feature-X branch company-project-feature-Y/ <-- worktree on feature-Y branch This way, too, I can easily use the same ephemera scripts across multiple branches, or even multiple repos, concurrently.
    - junon 4mo ago

hk1337 4mo ago

~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO. my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things. the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.

b40d-48b2-979e 4mo ago
As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
- hk1337 4mo ago
  Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.
- mroche 4mo ago
  You may need to have certain directories be excluded depending on the programs you use. For example, the default Chrome profile location is within ~/.config, which includes cache data that can be multiple gigabytes in size.
  - b40d-48b2-979e 4mo ago
    Ouch. It doesn't respect `$XDG_CACHE_HOME`?
    - mroche 4mo ago
      Browsers are some of the most annoyingly configured applications out there.
  - Ferret7446 4mo ago
    That's what .gitignore is for ;)

judofyr 4mo ago

Not sure where I picked up this, but I’ve added this to my global Git ignore: attic That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.

williamjackson 4mo ago
I do this too! But I call it `.local`
- zahlman 4mo ago
  I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.
- bflesch 4mo ago
  Doesn't git automatically exclude all files starting with a dot?
  - micael_dias 4mo ago
    No
  - groundcontr01 4mo ago
    Hey do you have a GitHub I can look at?
    - bflesch 4mo ago
      I have nothing of value ;D
weinzierl 4mo ago
Mine is aux and I hide it by putting a .gitignore in it that just contains am asterisk (*), nothing else, that way it ignores itself and anything in it.

jeremyscanvic 4mo ago

I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!

barbazoo 4mo ago

Exclude sounds like a recipe for sadness.

wpollock 4mo ago

One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory). Machine-wide configuration is called "system" in git, and generally lives under "/etc".

globular-toast 4mo ago

Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).

juxtapose 4mo ago
Magit introduced me to them in the first place. :-D

uptown 4mo ago

Not really news. I worked with dozens of developers who have managed to ignore files in Git.

kevincox 4mo ago

The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet. My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.

wccrawford 4mo ago
I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain. In the future, I think I might just be less nice about it. I dunno.
- eyelidlessness 4mo ago
  I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake. It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context. Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.
- nomel 4mo ago
  Yeap. To reduce pain, you need to work with reality rather than ideals. If you work with a big group, you either add a few lines into your gitignore, or you write code to check for those very same files in your CI/PR system, because you're tired of reversing commits and rejecting PRs because you're the only one that cares about a few extra files.

dofm 4mo ago

Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.

tremon 4mo ago
That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?
- deleted 4mo ago
  [deleted]
- deleted 4mo ago
  [deleted]
- dofm 4mo ago
  I mean sure, if you're this worried about ten bytes and prefer instead to spend time endlessly lecturing new Mac-based submitters about the additional overhead of supporting Mac-based submitters.
  - saagarjha 4mo ago
    As a Mac user, you should tell them how to do a better job.
    - dofm 4mo ago
      This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of https://en.wikipedia.org/wiki/Narcissism_of_small_differences https://en.wikipedia.org/wiki/Narcissism_of_small_difference... Me, I am pragmatic. I have set this in my local config and I've added it to my repos to be certain. Because it's ten bytes.

tonymet 4mo ago

these are great for ignoring files by name, but you often want to ignore binary files or other files by type. Set a global hooks dir, and then block binary files in pre-commit by using file or checking the git index git config --global core.hooksPath ~/.config/git/hooks Or block large changes, because binary mods are often larger than a real diff.

PunchyHamster 4mo ago

another useful snippet [includeIf "hasconfig:remote.*.url:git@git.company.com:*/**"] path = /home/dir/per/company/config allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo config works for dir too [includeIf "gitdir:/home/user/src/work1/"] Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash

hmokiguess 4mo ago

git is so incredible, it never ceases to amaze me, what a timeless piece of software

lmf4lol 4mo ago

Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore ! I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me… And Today, it got s little bit better :-)

hungryhobbit 4mo ago

Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`. This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file). With `.gitattributes` in the root of your project, you can just add a line: `package-lock.json -diff` Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.

clates 4mo ago
> that is pure noise from a Git standpoint It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.
- po1nt 4mo ago
  It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.
  - gpvos 4mo ago
    DX = ? Developer experience maybe?
    - sisve 4mo ago
      Yes
  - nine_k 4mo ago
    The point is that it should not be massive.

codymisc 4mo ago

[flagged]

leleat 4mo ago

There is also git update-index --[no]-skip-worktree for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.

oezi 4mo ago
This is what I use for making changes to local settings.json. Works nicely.

elyobo 4mo ago

Relatedly, some aliases I have in place. assume = update-index --assume-unchanged unassume = update-index --no-assume-unchanged assumed = "!git ls-files -v | grep ^h | cut -c 3-" unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged" assumeall = "!git st -s | awk {'print $2'} | xargs git assume"

arikrahman 4mo ago

[dead]

andrelaszlo 4mo ago

Here's how I use the excludes file to set a different config for a project directory containing multiple repos: https://laszlo.nu/blog/project-level-git-config.html https://laszlo.nu/blog/project-level-git-config.html

sgc 4mo ago
I *literally* cannot read that yellow text on the white background. I even tried changing the brightness to almost 0, but there is just not enough contrast.
- andrelaszlo 4mo ago
  Oh no, I forgot to test light mode. Thanks for letting me know! I'll fix it as soon as I'm in front of a computer. Happy Midsummer!
- andrelaszlo 4mo ago
  Fixed now, thanks again for your feedback!

antisol 4mo ago

Point of pedantry: > The ignore file lives in your machine’s home directory in ~/.config/git/ignore. Whatever filenames are added to this file are ignored globally at a machine-level. The wording here is slightly wrong: ~/.config/git/ignore will ignore files per-user on the machine, not "at a machine level". And it's not "your machine's home directory", it's your user's home directory on that machine. Any other users on the same machine will not see this. Git calls this "global", as in "global for the user". Git config does also have a --system option which modifies the system-level config file, /etc/gitignore. You could probably ignore stuff at the system/machine level (hint: you don't want to), with this. I'd do something like: $ sudo git config --system core.excludesFile /etc/gitignore $ sudo touch /etc/gitignore Note however that user config will override this, so any user who has a core.excludesFile setting will not also look at your system level excludes file. Which is a pretty big caveat.

smw 4mo ago
Why would you expect something in your home directory to affect other users?
- antisol 4mo ago
  Why would you ask me that? I'm not the one who called it "your machine's home directory"

supermdguy 4mo ago

One trick I’ve used is creating a folder and then adding a .gitignore inside it with *. Then nothing in that folder gets tracked, without needing to add anything to the public gitignore. Didn’t know about .git/config though!

linhns 4mo ago
Yeah it's in the document but there are no examples on it.

dalton_zk 4mo ago

Nice, I didn't know the other options besides .gitignore

yieldcrv 4mo ago

but dont forget dockerignore if you use docker

h4kunamata 4mo ago

>~/.config/git/ignore This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels. I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.

atomicnumber3 4mo ago
Idk, I can imagine a specific weird usecase. I use IntelliJ. My coworkers don't. They don't want my .idea folder in git. (You're probably thinking "ok, yep, gitignore!" And you're right except my boss ideologically does not want any *hint* of what IDE you use in the repo. Including in the gitignore. So each person putting .vscode or .idea in their local config's ignore actually makes sense. (Relative to the nonsensical parent requirement... of course).
Ferret7446 4mo ago
That sounds like a you problem for not syncing your dotfiles across devices

adamgordonbell 4mo ago

you may have a personal notes.txt file in a repository that you don’t want to check into git but you also don’t want to add to .gitignore because it’s unique to your workflow. The exclude file lives in the .git directory of every Git repository but changes to it are not checked into Git Wtf. I've always wanted this, and it was right there.

benrutter 4mo ago
> Wtf. I've always wanted this, and it was right there. Haha, same! I was literally looking for this feature last week without realising. What could be more git- the problem is rarely that it can't do something, but the ergonomics of discovering how to make it work correctly.

nonoesp 4mo ago

git update-index --assume-unchanged path/to/file https://git-scm.com/docs/git-update-index https://git-scm.com/docs/git-update-index

stevage 4mo ago

Wow, how did I not know about the exclude file? I've had this need so many times - working on a shared repo where I want to ignore some files locally.

rmunn 4mo ago

I have a habit of writing myself notes in various .txt files, and then not cleaning them up often enough so they end up cluttering my `git status` view. I ended up with a solution not mentioned in the article: create a `scratch` directory, and a `scratch/.gitignore` file containing just one line: `*`. This makes Git ignore everything in the scratch directory, including that same .gitignore file — so I never accidentally check it into Git, and don't end up pushing my personal .gitignore settings onto my coworkers. Of course, I could have used .git/info/exclude for that, and not risked accidentally adding my `scratch` directory with `git add -A` or something. So I (re-)learned something (which I'd known about but forgotten) today. But as a reminder to anyone else who had forgotten this: .gitignore files are processed throughout the repo, not just at the top level. You can sprinkle them throughout the repo structure for finer-grained control, which may come in handy in some circumstances.

ivan888 4mo ago
There's also the global gitignore configuration (core.excludesfile=~/.gitignore_global), which for me contains things like: *.swp, .DS_Store, scratch, etc.

rlpb 4mo ago

Placing various artifacts (eg. build artifacts) inside the source tree always seemed like a historical mistake to me. It leads to various accidents such as people checking in their credentials and accidentally bundling such files in source distributions, for example. These consequences are real. Debian build tooling places build artifacts in the parent directory on the assumption that this is acceptable, but it then surprises people since it's not the norm anywhere else. Perhaps this ship has sailed. But I think it's worth pointing out that if you have an option, don't design things that place things inside the source tree if you can avoid it.

ramijames 4mo ago

I love these types of threads the most. I learn so much.

shinobi-apps 4mo ago

[flagged]

codensolder 4mo ago

something new i learned today, thanks!

maxlin 4mo ago

My first and hopefully only clash with the global ignore file was debugging why a project worked differently between machines. There was a global ignore on the machine I was working on (that I didn't place) that "smartly" tried to exclude "irrelevant" code / project files regardless of project. I see version control somewhat similarly as I see traffic laws. Sure, they could work in entirely different ways, Germans like their autobahns, but breaks to the norm in an otherwise planar field are rarely arguable for.

pacman1337 4mo ago

another way is to use shortcuts

p1024k 4mo ago

[dead]