4 ms·

I'm not sure about that. We had a new hire once add a ton of .DS_Store files because we forgot to ignore it at the repo level and they didn't have a global igno

I'm not sure about that. We had a new hire once add a ton of .DS_Store files because we forgot to ignore it at the repo level and they didn't have a global ignore set up. I don't see the point of committing files that have no purpose in the repo, especially these ones, that could change between users age potentially polluting the diffs. We added it to the ignore list and removed the files

littlestymaar 2y ago
Or you could have taught them how to add the ignore file on their computer so they won't be making the same mistake in any other repo or other projects… And you could have used the opportunity to teach them about using a version control altogether and how it they aren't supposed to just throw git commit -am "fix stuff" at every problem! The fact that they committed the .DS_store files shows there's a much deeper problem with how this employee works that something you can work around with a .gitignore file. Now the problem has just been hidden under the rug.
- aniforprez 2y ago
  We don't care if this problem is "hidden under the rug". We didn't even consider it to be a problem. One line added to the gitignore and no future hires will have the ability to do this. Why is adding lines to a gitignore a problem? We've looked at it maybe a handful of times since it was initialised
  - littlestymaar 2y ago
    You'll think about this discussion the next time it happens again on a nez git repo you've just created. Why is adding a .gitignore line a problem you ask, but then someone could ask why is committing those .DS_store files a problem in the first place… In both cases the problem is that you are adding garbage unrelated to the project.
WCSTombs 2y ago
I don't think that's a good argument. An inexperienced developer can inadvertently do a lot of damage in infinitely many ways, and your example is just one of them. I don't think it's a good principle to structure a code base to protect inexperienced coders from themselves, which is always going to be a losing battle. This may have been a missed opportunity for a teachable moment: - The new hire most likely used `git commit -a` without checking `git status` or `git diff`, which is bad practice. - The new hire probably didn't even know about their global .gitignore. IMO a better way to steer new developers in the right direction is simply code review, and I'd think even a pretty cursory review would have caught those .DS_Store files.
- aniforprez 2y ago
  We can do both those things and also take away their ability to add unwanted files which is exactly what we did. Why even allow things like this to happen when a single line to a gitignore solves it forever? The reason we saw those .DS_Store files in the first place was during PR review

littlestymaar 2y ago

Or you could have taught them how to add the ignore file on their computer so they won't be making the same mistake in any other repo or other projects… And you could have used the opportunity to teach them about using a version control altogether and how it they aren't supposed to just throw git commit -am "fix stuff" at every problem! The fact that they committed the .DS_store files shows there's a much deeper problem with how this employee works that something you can work around with a .gitignore file. Now the problem has just been hidden under the rug.

aniforprez 2y ago
We don't care if this problem is "hidden under the rug". We didn't even consider it to be a problem. One line added to the gitignore and no future hires will have the ability to do this. Why is adding lines to a gitignore a problem? We've looked at it maybe a handful of times since it was initialised
- littlestymaar 2y ago
  You'll think about this discussion the next time it happens again on a nez git repo you've just created. Why is adding a .gitignore line a problem you ask, but then someone could ask why is committing those .DS_store files a problem in the first place… In both cases the problem is that you are adding garbage unrelated to the project.

WCSTombs 2y ago

I don't think that's a good argument. An inexperienced developer can inadvertently do a lot of damage in infinitely many ways, and your example is just one of them. I don't think it's a good principle to structure a code base to protect inexperienced coders from themselves, which is always going to be a losing battle. This may have been a missed opportunity for a teachable moment: - The new hire most likely used `git commit -a` without checking `git status` or `git diff`, which is bad practice. - The new hire probably didn't even know about their global .gitignore. IMO a better way to steer new developers in the right direction is simply code review, and I'd think even a pretty cursory review would have caught those .DS_Store files.

aniforprez 2y ago
We can do both those things and also take away their ability to add unwanted files which is exactly what we did. Why even allow things like this to happen when a single line to a gitignore solves it forever? The reason we saw those .DS_Store files in the first place was during PR review