Live data from Hacker News

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

nelson.cloud

71–80 of 188 posts

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

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

DX = ? Developer experience maybe?

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

#72
post #8

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

Or use ~/.cvsignore for all the other things which use that same file.

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

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

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

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

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

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

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

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

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

#77
post #54
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.

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?

> If a single macOS user works on ten different projects, should all ten projects add that line,

Not only do people think that, they also think that every pet tool that every pet user might decide to use should also end up cluttering up .gitignores for every project on earth. Worse, these people have created whole templates for this, so they can start a new project with ignores for dozens of tools they don't even use. 9 out of 10 times, this includes a broken ignore for Vim swap files.

I think these people are crazy, and like you suggest, tooling that is particular to you should go in the user's ignore, and tooling particular to the project should go into the repo's ignore.

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

#78
post #8

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

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.

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

#79
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"

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

#80
post #54

Earlier quoted context omitted.

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?

> If a single macOS user works on ten different projects, should all ten projects add that line, Not only do people think that, they also think that every pet tool that every pet user might decide to use should also end up cluttering up .gitignores for every project on earth. Worse, these people have created whole templates for this, so they can start a new project with ignores for dozens of tools they don't even use…

I mean I was just making a quick pragmatic suggestion about a labour-saving change that might be more sensible in practice, given that, rather than being a "pet tool" from a "pet user", it's a default side-effect of a platform that is modestly common in the hands of open source developers (as well as a common accidental side-effect from handling tarballs supplied by Mac users to non-Mac users).

But I wouldn't want to deny anyone an opportunity to regularly rehash a narrow tribal complaint in the comments on a pull request. Yeesh.

Post reply on HN