4 ms·

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 mor

by dofm 5mo ago

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.

tremon 5mo ago
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?
- deleted 5mo ago
  [deleted]
- deleted 5mo ago
  [deleted]
- dofm 5mo ago
  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.
  - saagarjha 5mo ago
    As a Mac user, you should tell them how to do a better job.
    - dofm 5mo ago
      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_differences 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.
      - saagarjha 5mo ago
        No I just think they should be aware of what their OS is doing
      - gcarvalho 5mo ago
        To be fair, if I submit changes and don’t notice I added .vscode / .idea / my_notes.txt / .DS_Store / .swp then it was a sloppy job and I shouldn’t expect the project to adapt to ignore every possible garbage file so that I can continue carelessly “git add .”-ing I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?
    - deleted 5mo ago
      [deleted]
- deathanatos 5mo ago
  > 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.
  - dofm 5mo ago
    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.
- hennell 4mo ago
  > If you have more than one They already answered your situation in their post.
tom_ 5mo ago
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!
- dofm 5mo ago
  Perhaps that is the norm for the command line tools now anyway, yes.

by dofm 5mo ago

tremon 5mo ago

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?

deleted 5mo ago
[deleted]
deleted 5mo ago
[deleted]
dofm 5mo ago
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.
- saagarjha 5mo ago
  As a Mac user, you should tell them how to do a better job.
  - dofm 5mo ago
    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_differences 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.
    - saagarjha 5mo ago
      No I just think they should be aware of what their OS is doing
    - gcarvalho 5mo ago
      To be fair, if I submit changes and don’t notice I added .vscode / .idea / my_notes.txt / .DS_Store / .swp then it was a sloppy job and I shouldn’t expect the project to adapt to ignore every possible garbage file so that I can continue carelessly “git add .”-ing I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?
  - deleted 5mo ago
    [deleted]
deathanatos 5mo ago
> 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.
- dofm 5mo ago
  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.
hennell 4mo ago
> If you have more than one They already answered your situation in their post.

tom_ 5mo ago

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!

dofm 5mo ago
Perhaps that is the norm for the command line tools now anyway, yes.