Hacker News Reader

Comment by Waterluvian | Hacker News Reader

DS Store seems so unfortunate. Yes it serves a purpose. Yes you can work around it in various ways. But the reality is that it’s basically proliferated file litter to 99% of people who come across it. It’s uncharacteristically un-Apple in terms of UX polish.

Growing up with both System 7.5 / OSX, and windows machines, the Macs never seemed inclined to make me see extraneous files, filetypes, and other “how the computer works” implementation details. It’s just so odd to my mental model of it all to see this file end up everywhere.

View on HN

For those who live their whole life within Apple's walls, they will never see .DS_Store files, unless they use the Terminal. Finder (with hidden files shown) doesn't even show them anymore.

It is very ugly when files are shared from a Mac to people on Windows though. I think it gives a bad first impression for anyone who might be thinking of transitioning to the Mac.

They pop up in code repositories too, depending on contents and whether the engineer in question noticed it.

absolutely essential to add a line for .DS_Store in every .gitignore, unfortunately.

Enough to teach people to use a global git core.excludesfile, IMO.

Same place you should put rules for Emacs / Vim swap files.

Totally correct. Files which are unrelated to the project don't belong in .gitignore.

This may be technically correct, and I do have .DS_Store in my global, but I also put it in projects, because I know not everyone on my team is going to do that. I add it to the .gitignore in projects to save me from other people junking up the project. It’s a lot easier to add some lines to a file than it is to micromanage the global file for every potential future contributor.

This touches on something I've learned to be more mindful of: the "right answer" (especially to a techie) is often not the right answer in real world cases.

I’m fine with the occasional .DS_Store getting added, because you can just remove it afterwards. Most of my work is either my own projects or at work, and whether people at work commit .DS_Store files is a question that touches on code reviews, company onboarding guides, etc.

Maybe the benefits / drawbacks would be different for an open-source project with a lot of contributors.

Just add a like to your onboarding docs to teach what the global ignore file is and how to manage it. the have them add a line for DS_Store.

It makes sense to add an ignore for .* though and then specifically unignore only those dotfiles/directories that you actully want checked in.

or just ignore them globally once.

I've banned people before because they couldn't stop themselves from continuously uploading those useless ds files

Seems like you have control issues.

Nah, those people have issues controlling their machines. It's fine if you upload useless spam a few times, but at some point you need to quit it because you're creating unnecessary work for others.

Well I was trying to tell you nicely, but you’ll figure it out before long.

Banning someone because they commit a file you don’t like is definitely a sign of a controlling person.

Repeatedly. Besides, if you repeatedly pay such little care how can anything you do be trusted?

You’re right, people are born perfect so this is felony behavior. We should limit their rights as a result.

Thanks for giving me a new interview question.

Stop being ridiculous. If you can't learn from your mistakes, even after it has been explained to you several times, you're the problem.

> limit their rights

Now you're just being weird. No one has an inherent "right" to contribute to a project.

Yea you missed the point. The point being you’re overreacting to a nonissue. But regardless it’s easy enough to filter your types out of my own projects and teams so I don’t care anymore.

lol, ok bro. glad to not have to work with you as well since you're really channeling that "can't learn from my mistakes and will keep burdering others with them! Wait, why don't you like me?" energy

> It’s uncharacteristically un-Apple in terms of UX polish.

Apple's polish has always been more about the surface then the internals.

I remember playing around with setting up a Hackintosh, and found all those errors in the system logs --- then realised that an actual working Mac generates much the same (ignorable) errors.

To be fair to Apple here, so does every other operating system. Linux system logs are filled with errors too. In general, keeping the logs of even a moderately complex application "clean" - so that the only errors logged are real errors, in some poorly defined meaning of "real" - is very hard.

For operating systems it must be straight up impossible.

> Linux system logs are filled with errors too.

Mostly only due to misbehaving hardware. Something that should really not happen on a Mac. And "filled" is way hyperbolic, there usually isn't a lot of it.

It's difficult to accept as competency when they control both the software and hardware.

Reply on news.ycombinator.com