Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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 :-)

    by lmf4lol
  • 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.
    by antisol
  • Why would you expect something in your home directory to affect other users?
    by smw
  • 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"
    by elyobo
  • 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.

    by rlpb
  • 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.
    by bryancoxwell
  • For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.
    by digikata
  • Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
    by RSHEPP
  • 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".

    by wpollock
  • 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.

    by dofm
  • I couldn't say for sure where it came from, but both my Macs (one with Ventura, one with Sequoia) have a ~/.gitignore_global file with an entry for .DS_Store, plus whatever stuff in the global git config makes git ignore stuff mentioned in that file.

    This file on my newer Mac is dated 2 days before I ordered it, and I don't remember setting any of this up, so I assume it came like this out of the box. I can't remember the dates for my older Mac, but I assume it's the same thing - and the macOS versions suggest that the default setup might have been like this for a while now.

    So, perhaps the days of having to add .DS_Store/ to your .gitignore file are over!

    by tom_
  • 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?
    by tremon
  • 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.
    by judofyr
  • mine's `scratch/`

    hasn't tripped me up (yet)

    by thewisenerd
  • I do this too! But I call it `.local`
    by williamjackson
  • 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.
    by weinzierl
  • You can also sort of invert this, but you have to do it on a case by case basis.

    Let's say you have a directory like attic; you can put inside a `attic/.gitignore`:

      /**
    & then that directory (and anything in it) is ignored, including the ignore file itself.

    I usually name my version of this directory the single character U+1F4A9, which HN refuses to permit me to put in a comment ;)

    by deathanatos
  • ~/.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.

    by hk1337
  • Or use ~/.cvsignore for all the other things which use that same file.
    by coryrc
  • As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
    by b40d-48b2-979e
  • 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.

    by rmunn
  • There's also the global gitignore configuration (core.excludesfile=~/.gitignore_global), which for me contains things like: *.swp, .DS_Store, scratch, etc.
    by ivan888
  • 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.

    by kevincox
  • .DS_Store
    by paulddraper
  • I'd rather have a pristine repo (no .ds_store/.idea/etc) than a pristine .gitignore file.
    by kortex
  • Or if your editor is happy to store them in a subfolder that is useful. I use Sublime with the AutoProjects extension and it puts .sublime-project snd .sublime-workspace under a .sublime folder that I can have a .gitignore * underneath.
    by mjmas
  • Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?
    by mvdtnz
  • I prefer gitignore since it survives dev container rebuilds.

    I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.

    by 8cvor6j844qw_d6
  • You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.
    by Anon1096
  • 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.

    by wccrawford