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.

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.

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.

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.

    attic

> 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.

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.

Machine-wide configuration is called "system" in git, and generally lives under "/etc".

  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"

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 :-)

  git update-index --[no]-skip-worktree

    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

~/.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.

https://laszlo.nu/blog/project-level-git-config.html

https://git-scm.com/docs/git-update-index

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.

  > 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.

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

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

    [includeIf "hasconfig:remote.*.url:git@git.company.com:*/**"]
    path = /home/dir/per/company/config

works for dir too

    [includeIf "gitdir:/home/user/src/work1/"]