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
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
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!
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.
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.
Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons.
And while you're free to play holier-than-thou at your job as you like, I'd give hell to anyone wasting my team's time like that.
As a DevOps guy (but with 30 years of experience in development too), one of my pet peeves is having to deal with a thousand different edge cases because someone decided that intellectual cleverness was more important than a holistic approach to design and architecture.
They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs and current implementations, rather than the myriad of alternate practices that software shops everywhere devise.
I've done migrations like these before -- while the parent poster may be doing all that for the wrong reasons (puritanism) they are absolutely right to do them.
The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it. If that breaks your new VCS, maybe migrating to it isn't such a good idea?
Not some arbitrary files, but the ones that the VCS recommends, or at least allows, to be excluded locally, where it makes sense. See e.g. github' note: https://docs.github.com/en/get-started/getting-started-with-... on the matter.
Also not a hypothetical new VCS, I've seen this backfiring several times, and it's usually not related to how good the new VCS is. E.g. when doing a ClearCase -> SVN migration years ago, just cutting out a few global exclusion rules that should have been local (e.g. tags files for people who liked etags, cscope.files for people who liked cscope) reduced a full-history migration time from several days to a few hours.
The two tools did not treat filename encoding the same way, so the migration tool had to walk through the exclusion list at every history point it synchronized. Due to how ClearCase presented its repositories (tl;dr userspace filesystem, years before FUSE) this was very slow on its first Linux versions (it had originally been offered for commercial Unices), not so much because ClearCase sucked but because it exposed a nasty quirk in the kernel's VFS implementation.
> The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it.
We're talking about ignoring file manager metadata files specific to some developers on some machines. .gitignore is global. Some details matter.
If you don't expect to ever do cross-platform migrations -- of even much cross-platform development, for that matter -- for repositories maintained across multiple platforms, yes, sure, you don't need that. That doesn't mean OP has a twisted view of adding value. Maybe his team does need that.
Edit: FWIW, migrations are just the nasty point that bites you back years later and usually comes with a huge bill. But puting all local exclusion rules in a single global file backfires in all sorts of ways on large and/or long-lived codebases. Sooner or later some eclusion rule specific to one developer's environment will do the wrong thing in another developer's environment.
I've seen all kinds of filters in a .gitignore for programs I don't personally use. I don't mind it at all.
I'm pretty sure I'll never create so many new projects in my entire career that those 8 seconds would add up to the amount of time required to follow your suggestion. Be a little more pragmatic, folks!
Using `~/.config/git/ignore` requires no extra setting.
> 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.
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.
git config --global core.excludesfile ~/.gitignore-global echo .DS_Store >> ~/.gitignore-global