Permalink
Browse files

gitignore: add .DS_Store

  • Loading branch information...
slimsag committed Dec 4, 2017
1 parent 9f4d689 commit c3c5e211b99fc66a5d94052fb35a159ae459da28
Showing with 1 addition and 0 deletions.
  1. +1 −0 .gitignore
View
@@ -0,0 +1 @@
.DS_store

4 comments on commit c3c5e21

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Dec 4, 2017

Member

Commit message says ".DS_Store", but the actual diff contains ".DS_store".

Also, in case it's helpful, it's very common to ignore ".DS_Store" globally rather than on a per-repository basis, by adding it to the global git ignore list (e.g., at ~/.config/git/ignore, but see https://git-scm.com/docs/gitignore for more info). The benefit is that you don't need to do it in every single git repository, and it doesn't pollute the top-level directory with an extra file.

Member

dmitshur replied Dec 4, 2017

Commit message says ".DS_Store", but the actual diff contains ".DS_store".

Also, in case it's helpful, it's very common to ignore ".DS_Store" globally rather than on a per-repository basis, by adding it to the global git ignore list (e.g., at ~/.config/git/ignore, but see https://git-scm.com/docs/gitignore for more info). The benefit is that you don't need to do it in every single git repository, and it doesn't pollute the top-level directory with an extra file.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Dec 4, 2017

Member

@shurcooL Thanks for writing this! I guess this should actually be **/.DS_Store probably. I'll see if I can write a TODO for myself to change this in the near future.

I tend to shy away from any personal configuration, so it feels really strange to ask e.g. every contributor to Vecty on a Mac to add this to their personal configuration rather than having it in the project... but maybe I'm wrong in thinking this?

Member

slimsag replied Dec 4, 2017

@shurcooL Thanks for writing this! I guess this should actually be **/.DS_Store probably. I'll see if I can write a TODO for myself to change this in the near future.

I tend to shy away from any personal configuration, so it feels really strange to ask e.g. every contributor to Vecty on a Mac to add this to their personal configuration rather than having it in the project... but maybe I'm wrong in thinking this?

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Dec 4, 2017

Member

I guess this should actually be **/.DS_Store probably.

No, just.DS_Store would be sufficient to ignore all files with that name in all subdirectories. My original comment was pointing out the mismatched case (store vs Store). It doesn't make a difference on case-insensitive filesystems, but it does on case-sensitive ones.

I tend to shy away from any personal configuration, so it feels really strange to ask e.g. every contributor to Vecty on a Mac to add this to their personal configuration rather than having it in the project... but maybe I'm wrong in thinking this?

I don't consider this personal configuration. .DS_Store is a macOS operating system-specific file, and ignoring it at a system scope makes most sense to me. Ignoring it at the repository-scope feels less appropriate, since it has nothing to do with the details of this project, especially for users/developers who are not on macOS.

It may vary depending on how you install git on macOS, but .DS_Store tends to be ignored by default. If it's not the case for you, I think that might be a more unusual occurrence or misconfiguration.

Member

dmitshur replied Dec 4, 2017

I guess this should actually be **/.DS_Store probably.

No, just.DS_Store would be sufficient to ignore all files with that name in all subdirectories. My original comment was pointing out the mismatched case (store vs Store). It doesn't make a difference on case-insensitive filesystems, but it does on case-sensitive ones.

I tend to shy away from any personal configuration, so it feels really strange to ask e.g. every contributor to Vecty on a Mac to add this to their personal configuration rather than having it in the project... but maybe I'm wrong in thinking this?

I don't consider this personal configuration. .DS_Store is a macOS operating system-specific file, and ignoring it at a system scope makes most sense to me. Ignoring it at the repository-scope feels less appropriate, since it has nothing to do with the details of this project, especially for users/developers who are not on macOS.

It may vary depending on how you install git on macOS, but .DS_Store tends to be ignored by default. If it's not the case for you, I think that might be a more unusual occurrence or misconfiguration.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Dec 5, 2017

Member

No, just.DS_Store would be sufficient to ignore all files with that name in all subdirectories. My original comment was pointing out the mismatched case (store vs Store). It doesn't make a difference on case-insensitive filesystems, but it does on case-sensitive ones.

Understood.

I don't consider this personal configuration. .DS_Store is a macOS operating system-specific file, and ignoring it at a system scope makes most sense to me. Ignoring it at the repository-scope feels less appropriate, especially for users/developers who are not on macOS.

  1. I agree that it's an OS-specific file, and ignoring it at a system scope makes the most sense if it's done by default.
  2. I don't think most developers care what is inside of .gitignore or if it contains OS-specific things (that is, I don't think a Linux developer will care if there is a Mac file inside of .gitignore).

It may vary depending on how you install git on macOS, but .DS_Store tends to be ignored by default. If it's not the case for you, I think that might be a more unusual occurrence or misconfiguration.

I was surprised to hear this because in my experience that has not been the case. But if it's true, I am happy to revert this change. I set out to determine if this really is true or not, but from what I have found it does not seem to be.

For example, there are 4.5 million .DS_Store files on GitHub apparently: https://github.com/search?utf8=%E2%9C%93&q=filename%3A.DS_Store&type=

I also could not find any definitive info online about whether or not it is ignored by default on any specific versions of OS X, only articles on how to add it to the global configuration.

Member

slimsag replied Dec 5, 2017

No, just.DS_Store would be sufficient to ignore all files with that name in all subdirectories. My original comment was pointing out the mismatched case (store vs Store). It doesn't make a difference on case-insensitive filesystems, but it does on case-sensitive ones.

Understood.

I don't consider this personal configuration. .DS_Store is a macOS operating system-specific file, and ignoring it at a system scope makes most sense to me. Ignoring it at the repository-scope feels less appropriate, especially for users/developers who are not on macOS.

  1. I agree that it's an OS-specific file, and ignoring it at a system scope makes the most sense if it's done by default.
  2. I don't think most developers care what is inside of .gitignore or if it contains OS-specific things (that is, I don't think a Linux developer will care if there is a Mac file inside of .gitignore).

It may vary depending on how you install git on macOS, but .DS_Store tends to be ignored by default. If it's not the case for you, I think that might be a more unusual occurrence or misconfiguration.

I was surprised to hear this because in my experience that has not been the case. But if it's true, I am happy to revert this change. I set out to determine if this really is true or not, but from what I have found it does not seem to be.

For example, there are 4.5 million .DS_Store files on GitHub apparently: https://github.com/search?utf8=%E2%9C%93&q=filename%3A.DS_Store&type=

I also could not find any definitive info online about whether or not it is ignored by default on any specific versions of OS X, only articles on how to add it to the global configuration.

Please sign in to comment.