Live data from Hacker News

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

nelson.cloud

91–100 of 188 posts

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

#91
post #67
post #66

Earlier quoted context omitted.

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

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.

> you just want to see that the file changed

I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).

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

#92
post #12

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.

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.

[deleted]

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

#93
post #32

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.

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!

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

#94
post #60

Earlier quoted context omitted.

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.

As a Mac user, you should tell them how to do a better job.

[deleted]

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

#96
post #93
post #32

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.

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 remembe…

Perhaps that is the norm for the command line tools now anyway, yes.

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

#98
post #67
post #66

Earlier quoted context omitted.

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

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.

It's a CLI. DX is not the only concern. What about scripts that expect the default git behavior?

You could argue "those scripts are dumb then! outta my way!", but then you shouldn't be using a CLI for whatever it is you're trying to do. If you insist, you can just grep or use the --stat option.

We already know the git CLI has plenty of antifeatures like this. It is up to the devs how they want to proceed, but it doesn't change the fact that hiding things is a footgun.

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

#99
post #78

Earlier quoted context omitted.

As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.

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.

Ouch. It doesn't respect `$XDG_CACHE_HOME`?

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

#100
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.
Post reply on HN