Hacker News Reader

Comment by Dobbs | Hacker News Reader

Additionally git supports a global git ignore.

    $ git config --global core.excludesfile ~/.gitignore

Then you can put all the standard things you want to ignore into it:

    $ cat ~/.gitignore
    .DS_Store
    ./drafts/
    *.swp

And it will apply to all git commands on your computer.

View on HN

I heavily advise AGAINST using this for anything apart from OS level file spam (.DS_Store etc).

We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project.

Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...

how did that project ever build on ci :)

but it worked on my machine

Ship your machine as CI, problem solved /s

docker wants to know your location

hint: there was no CI

I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.

Probably the dev made the code review before leaving

You might have learned the wrong lesson.

A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc.

Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations.

Also don’t code review the code it self, review the diff.

Yeah exactly, if I `require important.rb` in this file, and `important.rb` wasn't committed how did that project even build and get deployed. Any sane build system will instantly fail for this situations. Looks like an issue with dev ops/engineering culture rather than .gitignore

>Also don’t code review the code it self, review the diff.

A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.

Telling developers to not use the global .gitignore seems to be the wrong response. For example, I use VS Code, its extensions, and various other development tools that create local files that should not be in repositories. Those files and directories do not belong in a repository's .gitignore file, unless it's a personal project. They most often belong in a global .gitignore unless a team uses a common set of tools. Having a single developer's custom tools be handled by a repository's .gitignore seems to be the wrong approach.

.git/info/exclude seems like the right place for this.

That's only per repository, isn't it? It won't really be convenient when you're working across several repositories or languages.

If they did not commit all the important files and your CI system didn't catch that, that's definitely the fault of your CI system, not global gitignore.

so glad i don't work with you.

Why? They're right imo

fishywang's attitude

What attitude lmao. They’re very matter-of-fact in expressing an objective opinion from what I can see.

what perceptive skills lmao! i couldn't stand talking to you for 2 minutes.

lmao!

I don't understand, you'd rather work without a CI pipeline?

i'd rather not work with fishywang

Because there isn't a CI?

Shocking I know /s.

But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...

You don’t have to be at a tech startup to have things like CI and/or code review platforms.

Agreed. If the code is in GitHub, it's incredibly easy to create a simple github actions workflow that could run the app.

The global gitignore is super useful! I add a “.x” entry to it so that I can create scripts, drafts, etc in a “.x” folder in any of my projects.

Wrote more details about how I do this here: https://alexplescan.com/posts/2022/04/17/the-x-files/

You had me - before clicking - at the url-slug "the-x-files". Loved the content and learned something useful. Thanks for pointing it out. Will be another little tool in my belt.

just set this up on my machine! Thank you so much!

I'd just been bumping into this problem, but hadn't conceptualized such an elegant solution, so kept fumbling around, adding/moving things, futzing around with git way more than I wanted to.

Thank you!

This seems like it could potentially be a source of confusion - different devs on the same project would see different ignore behavior.

Not really, because they only see differences they have caused themselves, so they know about it.

And so they forget about it.

It is as soon as you forget about that-but, speaking of myself, it is not because I'm aware of the fact that I'm using it

As far as I can see, this only comes into play when newly adding files to be tracked. If you created a 'source.file', but your global gitignore ignores all '.file' files, then you'd notice immediately. You wouldn't commit and push because you were unable to add the file in the first place.

If another developer has added a 'source.file' and you pulled it in, your global gitignore would not be triggered, since the file is already tracked in the repo.

It would also come into play of you add code that generates files which should be ignored, but you don't realize the gitignore has to be updated because it's ignored in your own global gitignore.

Very good observation. That's a reason I'm itching to try out an approach akin to this (in a future project): https://jasonstitt.com/gitignore-whitelisting-patterns

Excellent point!

Tangentially, to prevent scenarios where generated code becomes out of sync, in your CI you should always re-run generators and check that `git status` shows no entries (and fail the build if it does).

As long as you know your own ignore behaviour, I don't see how it can cause confusion... except maybe if you share the drive the repo is stored (either as a network drive or you share the physical drive via sneakernet) but why would you do that instead of cloning the repo?

I wouldn't use this for system files, but I have the pattern "loz_*" and it lets me keep "my" odd scripts in the repo folder but permanently untracked.

In many ways that’s a good thing. I don’t want to have ignore entries for 10 different text editors in every project’s .gitignore. Put that stuff in your personal .gitignore. In general, I don’t want commit history to contain any of these “just for me” changes even aside from .gitignore. Project .gitignore should mostly just ignore the stuff that your build/CI produces, which itself should hopefully be just a single `build` directory.

This is the reality of the global .gitignore. Unless you have a full team of super competent and well rounded devs that think alike, one is going to come up with a strategy of "ok, everyone should obviously put stuff like .vscode in their global gitignore; it has no place in the local one" while somebody else doesn't care a bit, and it's really kind of a silly thing to try and enforce protocol around. Much bikeshedding detected.

I agree. The same problem (different devs with different settings) is solved by specifying line endings in per-repo .gitattributes files instead of global autocrlf settings. And we all know how much confusion that causes.

I am surprised this isn't expected. Sure, it's nice to have common build files ignored. But I have all kinds of files locally (editor files, etc) that are specific to me, not common to my team. I don't expect my team to have the same ignore list as me, nor would I want my ignore list cluttered with entries that only apply to them. I see it the same as an editor/IDE config; each person has their own, and putting them in version control tends to cause issues/noise.

Is this a problem though? I can see the upsides of ignoring the files in the shared gitignore. Are we trying to save space??

Yes it is a problem when a project involves more than a few people. If there are really common ignores that multiple people use, it’s fine to share those. But one-off folder & file ignores should not be dumped into the shared space. It has nothing to do with disk space, and everything to do with clean semantic project organization. Shared ignores should be primarily a declaration of temporary files & folders that the project produces during build/run/etc. - things that everyone will need. Adding personal folder ignores to the shared .gitignore can not only be confusing about what intermediate artifacts are expected, it can cause problems or conflicts for other people. A small dumb example is if someone tries to make a new shared folder and someone else already shared an ignore. I’ve seen it happen, and it’s not a big deal, but caused temporary confusion. You can cause issues with git history and pulls and bisects when there’s churn with the ignores.

Back on earth, a few lines in an ignore file would not make anyone blink. I guess you're a purist and everything about your software shines! Perfection.

> Back on earth, a few lines in an ignore file would not make anyone blink. I guess you're a purist and everything about your software shines! Perfection.

I didn’t downvote you, and I don’t understand your sarcasm toward me when I’m trying to explain the practical answer to the question you asked. This isn’t just a few lines on a large project, and it’s not even about the extra lines at all. The issue is that personal preferences don’t belong in a shared file, and their presence can cause real and actual problems in a large project, problems I’ve witnessed and experienced first hand. One single bad line in .gitignore can cause trouble for everyone on the team when they need to checkout different branches. If you have 50 or 100 people adding their own ignores, they can and do easily conflict with each other. The shared .gitignore just isn’t the spot to list your personal folders, which is why git designed other places for you to put those.

This is by design, and not a problem in practice: ignores are declaring unshared files & folders. If ignores change the state or behavior of the project, it means someone didn’t use ignores correctly, didn’t think through what ignore behavior should be shared and what shouldn’t. Sometimes there are folders everyone will have that should be ignored, like a “build/“ folder, and sometimes there are folders you make yourself inside your repo and don’t want them checked in, like test scripts or output images or whatever. The personally ignored artifacts should be different ignore behavior.

Global gitignore should in general only be used for things that's "unique" in your local environment, like:

* IDE/Editor (for example, add `.vscode` to your global gitignore if you use VSCode, add `.idea` if you use IntelliJ family, NOT add `.editorconfig` because that's intended to be cross environment)

* OS level spam (`.DS_Store`, etc.)

* Any file generated by a tool you use locally

Also a pro tip, I have this alias in my global git config:

    why-ignore = check-ignore -v --no-index

So I can use `git why-ignore path/to/file` to show why a file is ignored (e.g. it shows which line in which gitignore file excluded it).

Thanks for pro tip, git clean -ndx is my friend.

I also got in my ~/.gitignore:

    .envrc   # direnv, where I store my local project configuration
    .vscode

and when I remember to use them:

    *.gitlocal
    *.gitlocal*

To store files and directories I don't ever want to push, mostly for scratch files and logs

Why to ignore .vscode? We collect there workspace wide team settings.

I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great.

Anyway, stuff in .gitignore can still be added to the index if you so wish.

If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.

When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration.

Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy.

There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.

I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.

I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case.

What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.

For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.

I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file.

Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else.

I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use.

Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar.

Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.

I've seen a few big repositories upload their .vscode (pretty sure at least one of the Microsoft repos on Github had this).

I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).

What about .editorconfig?

That's perfectly fine, mandatory even if more than one person touches the code.

you didn't list .idea :'(

Please never commit IDE config. It doesn't belong in repositories. It is not a source file of your project.

Actually, this can be quite useful (at least with IntelliJ) to share common run configurations (e.g., run all tests, start this server with these settings) and other settings.

IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206...

Makefile or adding those scripts to package.json is a much better idea than vscode's own task configuration file which might not work if someone uses another editor.

Why not both?

'never' is a strong word.

A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project.

If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to:

   git clone <project>
   git switch -t <branch>
   code <project>
   npm ci | dotnet restore | terraform init | go get | <whatever>
   <change and test>
   git add <changes>
   git commit
   git push

With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes.

It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.

Never is a strong word, and I mean it. No your fancy extensions mean nothing to many devs. That configuration is not required to run the code in the repository. Do not include it.

So... are you also against having any hints as to how to set up a working local dev environment in the README.md file? Because that's also not necessary to run the project, but it's a courtesy to contributors.

Also, the idea that there is some universal rule of 'what should be checked in to source control' that applies to EVERYTHING from personal projects to corporate internal monorepos to open source projects to undergrad joint coding projects to video games is... absurd.

No, because that's documentation, but I think that was obvious.

Well, no it's not obvious.

If I can provide machine readable documentation on how to get your VSCode environment set up (in the form of a .vscode/extensions.json file), isn't that strictly better than merely human-readable documentation in README.md under a 'Recommended VSCode Extensions to work with this project' header?

No, because that doesn't translate to other IDEs and one user programmatically changing things to suit themselves causes fluff in PRs and diffs. You also can't guarantee every environment is going to respond correctly.

One user programmatically changing things to suit themselves is supposed to do so in their user settings, which has precedence over the checked-in copy. That way, you have the best of both worlds: easy set-up for everyone who wants it but you can override it without touching the VCS.

Can you override user settings at the project level?

Yes, project-level (aka workspace) settings generally override user settings.

But then again, language-specific settings will trump all other settings. And that’s one way to override workspace-level settings in your user settings if you want.

Here’s a detailed list of all levels of settings in VS Code, ordered by precedence: https://code.visualstudio.com/docs/getstarted/settings#_sett...

Update: turns out the precedence rules are a little more subtle than I thought.

Java projects can get complex and editors (like IntelliJ can provide much better tooling when configured).

At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.

It’s definitely not a never situation. You can commit only certain files from the configuration (project settings not editor preferences)

I think I disagree, though the only person who should be messing with it is the maintainer. One of the easiest ways to ensure that everyone follows the same coding standard for a project (particularly for open source projects).

I usually add something like specified in:

https://editorconfig.org/

But there's a difference between editorconfig and vscode specific stuff in that editorconfig is IDE agnostic...

Yes; would be silly to dictate people's font sizes and the like. Perhaps we can then agree that there are certain configs that do belong, and others that might be less wise to include [if your boss dictates that you use Arial 10pt, get another job!]

Most teams I worked on did not standardize the team's OS or editor. The "canonical" build was a CI server and the development environment was available as a VM or container.

For the love of God no. I had someone commit theirs and it override my preferred setup and even changed my gd font. You're basically telling your teammates: i am forcing you to work my way so shove it.

I do the same with with *gitignored*. Handy for output files of tests, and log files. For example: "log_gitignored.txt" or "mesh_transformed_gitignored.stl".

I add it to the repository settings, so all collogues have the same behavior.

Standard path is ~/.config/git/ignore

You mean $XDG_CONFIG_HOME/git/ignore

"For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the ~/.gitconfig file doesn’t."

Everyone aren't using all the freedesktop conventions, so no.

To supply context: the above quote is from the man page, therefore authoritative.

  $ man git-config

It is however densely conditional wording -- could be simplified.

I don't think that XDG_CONFIG_HOME is a thing with Windows or macOS.

I've got a slightly different version of that last rule in mine:

    *.sw?

Since I'm messy enough to sometimes end up with multiple of them for a few files. (Also, not messing with flash files in git, or in general...)

But have since moved my vim swap files to ~/.vim/swap with `set directory=~/.vim/swap,.` in .vimrc.

ignoring .swf is a bonus :P

Or simply put the file at the default location for core.excludefile, which is

    ~/.config/git/ignore

on Unixy platforms.

Hard agree. Even though I tend to work on only a couple of different kinds of things - at least for now - the global ignore file is a godsend.

So good.

Reply on news.ycombinator.com