Comment by remram
3 years ago
I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?
3 years ago
I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?
They're just a file, so git can see it. Good habit would be to add it to the project's gitignore, or your global gitignore (or both)
It's a pet peeve of mine when people put stuff like this in a project's `.gitignore`. The proper place is either your global gitignore (probably appropriate for stupid stuff like this) or in your clone in `.git/info/exclude`.
`.gitignore` is for stuff that all developers need to ignore, like compiler output, and should be kept to the bare minimum.
> .gitignore` is for stuff that all developers need to ignore
But that is the case, all developers need to ignore the ".DS_Store" files. So by your own rule it is appropriate in there then?
5 replies →
I can see an argument for this being semantically correct, but in practice I think it's preferable to have the repo checkout in the closest configuration to correct for new developers who will start contributing.
And, for what it's worth, all developers need to ignore .DS_Store files regardless if Finder creates it or it gets placed in when you unzip something created on a Mac, for instance.
In the best case, you spend extra time needlessly denying PRs and bothering people who already likely don't know git well enough to cleanly fix their commit. In the case of a repo large enough that you're not the only person approving PRs, I'd say it's almost inevitable that they eventually slip through.
Just my 2¢ from experience working in the industry.
TIL there's a global gitignore, thanks!
So they are not a resource fork, then.
They are visible to programs, for example if you run `ls -a` you will see them on macOS too. I reckon they're only transparent to Finder (where you can't see them even if you're showing hidden files).