5 ms·

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid f

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

srhtftw 4y ago
I instinctively delete these .DS_Store files whenever I see them but your "creative uses" comment makes me think given common .gitignore practice this might be a great place for AWS keys or whatever you never want checked into VCS /s
pilif 4y ago
nitpick: As it’s a platform and machine specific thing, technically it shouldn’t be in .gitignore but in .git/info/exclude People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine. I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones. That said, as a purist, none of the repos I’m watching over have .DS_Store in their gitignore
- account42 4y ago
  I agree that platform-specific files shouldn't be in .gitignore, but it does make sense to put .* there and then only allow specific .files that you actually want to check in.
- MBCook 4y ago
  Also there is a preference you can set with the defaults command to stop MacOS from putting them on file systems it encounters.
- dopidopHN 4y ago
  Interesting, I guess I live in impur lands :) I understand the pollution concern… but unless that .git/info/exclude is standard in the company, what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? .gitignore looks more robust to the obvious user. And it’s not like it’s a file you need to look at attentively every day. But yes, I do see that you are correct!
  - pilif 4y ago
    > what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? Our CI. And code review is what prevents .DS_Store to be added to .gitignore. And, again, I'm saying this as a purist with a developer team of 99% Mac users.
    - dymk 4y ago
      So now you leak that kludge into CI, and waste code review cycles, when it could have just been in .gitignore
    - 9dev 4y ago
      If anyone on my team even dared to waste time on this discussion, let alone add CI checks or instruct the team about putting the exclude from A to B, we’d had a serious conversation about generating business value, cargo culting, and the purpose of code in general. Fascinating.
      - lobstrosity420 4y ago
        This is why it’s important to do a culture fit evaluation on top of a technical evaluation. An unpopular opinion here for sure.
      - danielhep 4y ago
        [flagged]
      - pilif 4y ago
        Some of the repos we work on date back to 2004 (going from CSV to Subversion, to git. Developers moving from mostly Windows to mostly Linux, to mostly macOS). If everybody was free to check in debris of whatever IDE and/or OS they were working at any given time, the codebase would be a terrible mess, especially as such debris tends to go unnoticed for ages until it's not. Just like we have CI checks to make sure nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards. All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one. Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.
- monkellipse 4y ago
  An informative nitpick, thank you.
- charcircuit 4y ago
  By that logic it should be in your global excludes file. It practice it will save more time if you just add it to your project's .gitignore instead of wasting time having everyone else configure their system. O(1) amount of work compared to O(n)
  - pilif 4y ago
    yes. it's in-fact there. But that's one more level of indirection from the "problem" at hand (because the global excludes file needs a config setting for it to even be considered, whereas .git/info/exclude is present in every repo)
    - matijs 4y ago
      > because the global excludes file needs a config setting for it to even be considered Using `~/.config/git/ignore` requires no extra setting.
      - pilif 4y ago
        Oh. TIL. Thank you
- WanderPanda 4y ago
  Interesting! The kind of answer ChatGPT can not produce (afaik) because it is too far from the mean mode of how the world is operating
- chrisfosterelli 4y ago
  I think this depends on how you interpret it. All the docs[0] say are: > Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file. and > Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. To me it seems obvious that all developers would want to ignore .DS_Store even if only some of them would generate it. And certainly you want it distributed to other mac users when they clone. Further, it's certainly not the case that .DS_Store is specific to just one user's workflow. On all three cases therefore gitignore would be reasonably appropriate. [0]: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore
- jillesvangurp 4y ago
  As long as that isn't set up by default, you can't rely on that being setup correctly for everyone or even most people. So .gitignore should include the file regardless of that setting.
50 4y ago
> The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase I stole this from somewhere: Create a .gitignore_global file and include .DS_Store, then in the [core] of your .gitconfig include excludesfile = /Users/janedoe/.gitignore_global.
whalesalad 4y ago
You can ignore it in your global git config, too. Once per host.
- rjmunro 4y ago
  Something like: git config --global core.excludesfile ~/.gitignore-global echo .DS_Store >> ~/.gitignore-global
  - yrro 4y ago
    You don't need to set core.excludesfile any more, it defaults to ~/.config/git/ignore these days
tannhaeuser 4y ago
Having .DS_Store all over the place sucks, but to be fair so does having other dot files, such as .git which is an entire subdir even. At least the convention of hiding dot files from file listings is uniformly observed.
- account42 4y ago
  The difference is that .git is only in directories that you explicitly set up as a git repository whereas .DS_Store, Thumbs.db, .desktop and similar get barfed wherever by the file manager without doing anything that a user would consider as a modification to the directory.
planede 4y ago
Arguably if you work on a mac and you use git regularly then just add it to ~/.config/git/ignore, and it will be ignored everywhere.

srhtftw 4y ago

I instinctively delete these .DS_Store files whenever I see them but your "creative uses" comment makes me think given common .gitignore practice this might be a great place for AWS keys or whatever you never want checked into VCS /s

pilif 4y ago

nitpick: As it’s a platform and machine specific thing, technically it shouldn’t be in .gitignore but in .git/info/exclude People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine. I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones. That said, as a purist, none of the repos I’m watching over have .DS_Store in their gitignore

account42 4y ago
I agree that platform-specific files shouldn't be in .gitignore, but it does make sense to put .* there and then only allow specific .files that you actually want to check in.
MBCook 4y ago
Also there is a preference you can set with the defaults command to stop MacOS from putting them on file systems it encounters.
dopidopHN 4y ago
Interesting, I guess I live in impur lands :) I understand the pollution concern… but unless that .git/info/exclude is standard in the company, what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? .gitignore looks more robust to the obvious user. And it’s not like it’s a file you need to look at attentively every day. But yes, I do see that you are correct!
- pilif 4y ago
  > what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? Our CI. And code review is what prevents .DS_Store to be added to .gitignore. And, again, I'm saying this as a purist with a developer team of 99% Mac users.
  - dymk 4y ago
    So now you leak that kludge into CI, and waste code review cycles, when it could have just been in .gitignore
  - 9dev 4y ago
    If anyone on my team even dared to waste time on this discussion, let alone add CI checks or instruct the team about putting the exclude from A to B, we’d had a serious conversation about generating business value, cargo culting, and the purpose of code in general. Fascinating.
    - lobstrosity420 4y ago
      This is why it’s important to do a culture fit evaluation on top of a technical evaluation. An unpopular opinion here for sure.
    - danielhep 4y ago
      [flagged]
    - pilif 4y ago
      Some of the repos we work on date back to 2004 (going from CSV to Subversion, to git. Developers moving from mostly Windows to mostly Linux, to mostly macOS). If everybody was free to check in debris of whatever IDE and/or OS they were working at any given time, the codebase would be a terrible mess, especially as such debris tends to go unnoticed for ages until it's not. Just like we have CI checks to make sure nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards. All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one. Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.
monkellipse 4y ago
An informative nitpick, thank you.
charcircuit 4y ago
By that logic it should be in your global excludes file. It practice it will save more time if you just add it to your project's .gitignore instead of wasting time having everyone else configure their system. O(1) amount of work compared to O(n)
- pilif 4y ago
  yes. it's in-fact there. But that's one more level of indirection from the "problem" at hand (because the global excludes file needs a config setting for it to even be considered, whereas .git/info/exclude is present in every repo)
  - matijs 4y ago
    > because the global excludes file needs a config setting for it to even be considered Using `~/.config/git/ignore` requires no extra setting.
    - pilif 4y ago
      Oh. TIL. Thank you
WanderPanda 4y ago
Interesting! The kind of answer ChatGPT can not produce (afaik) because it is too far from the mean mode of how the world is operating
chrisfosterelli 4y ago
I think this depends on how you interpret it. All the docs[0] say are: > Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file. and > Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. To me it seems obvious that all developers would want to ignore .DS_Store even if only some of them would generate it. And certainly you want it distributed to other mac users when they clone. Further, it's certainly not the case that .DS_Store is specific to just one user's workflow. On all three cases therefore gitignore would be reasonably appropriate. [0]: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore
jillesvangurp 4y ago
As long as that isn't set up by default, you can't rely on that being setup correctly for everyone or even most people. So .gitignore should include the file regardless of that setting.

50 4y ago

> The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase I stole this from somewhere: Create a .gitignore_global file and include .DS_Store, then in the [core] of your .gitconfig include excludesfile = /Users/janedoe/.gitignore_global.

whalesalad 4y ago

You can ignore it in your global git config, too. Once per host.

rjmunro 4y ago
Something like: git config --global core.excludesfile ~/.gitignore-global echo .DS_Store >> ~/.gitignore-global
- yrro 4y ago
  You don't need to set core.excludesfile any more, it defaults to ~/.config/git/ignore these days

tannhaeuser 4y ago

Having .DS_Store all over the place sucks, but to be fair so does having other dot files, such as .git which is an entire subdir even. At least the convention of hiding dot files from file listings is uniformly observed.

account42 4y ago
The difference is that .git is only in directories that you explicitly set up as a git repository whereas .DS_Store, Thumbs.db, .desktop and similar get barfed wherever by the file manager without doing anything that a user would consider as a modification to the directory.

planede 4y ago

Arguably if you work on a mac and you use git regularly then just add it to ~/.config/git/ignore, and it will be ignored everywhere.