Let's hope that people who resort to clickbait titles never complain about dark patterns in software, because what they do is analogous, they're tricking me to their advantage.
"...for your personal files"
41–50 of 72 posts
Let's hope that people who resort to clickbait titles never complain about dark patterns in software, because what they do is analogous, they're tricking me to their advantage.
"...for your personal files"
Earlier quoted context omitted.
Yeah, people putting MacOS-specific files that have no relation to the codebase in the .gitignore should stop.
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
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.
>I think most people are aware of the repo’s git ignore file Not me, never heard of it. I use ./.git/info/exclude to bypass commits and pushes, that is good enough for me. Quickly reading the title, I though it was about stop using git period, go to something else :)
This is bad advice. The repo’s ignore file is there so that other people (without certain domain knowledge) don’t accidentally commit undesirable files, including directories containing sensitive information (which get generated by some tools like Terraform). Use the repo’s ignore, not your own.
Using a user gitignore file works if you’re responsible for your development environment. This does not work for other developers who are not responsible for their development environment. The first place to catch errant build files and artifacts from entering the repo database is the .gitignore file. The second place to catch them is the PR. The .gitignore prevents repetitive file adds from entering the PR. What I d…
I will look into this idea. Thanks again
Earlier quoted context omitted.
Thank you for reading and commenting. It is great to understand different people's perspectives. From my experience the main downside of keeping the "guardrails on", people are less likely to learn about the importance of git global ignore and also with open source projects there can be a green square chasing game (which we also need to educate people on) - just thinking about this, more Pull Requests will come in wi…
You've mentioned the "green square game" a lot, and I don't see how this is a problem. If someone makes a PR that is nothing but the .gitignore file, you can just reject it in one second. (Unless it is a well-researched and well-justified change, in which case you can gratefully merge it.)
This is bad advice. The repo’s ignore file is there so that other people (without certain domain knowledge) don’t accidentally commit undesirable files, including directories containing sensitive information (which get generated by some tools like Terraform). Use the repo’s ignore, not your own.
Yes we should use git ignore for the repo specific items, so if the repo has terraform it should ignore generated files - but not desktop tools people use as we all use different dev tools
Earlier quoted context omitted.
Why is it a problem to have a long .gitignore?
Committing stuff to the repo means work for other people (namely the reviewers). And to find the answer to “why is it a problem that there's a .sublimetext line in the .gitignore” then ask yourself the question “why is it a problem if there's a .sublimetext file committed to the repository”. Why even bothering to add it to the .gitignore when you can just commit the file? Why do you think the second scenario is an is…
Problems listed in the article: > Everyone uses different operating systems, IDEs and dev tools. How is this related to .gitignore? > This list will only keep growing, it will never end Where's the problem? A random Facebook's repo has its gitignore file weigh 2KB[0]. Is this a problem? > Is the “.gitignore” file competing with the “README.md” for the most updated file in the git repo? I hope not Again, why is this a…
Than you for reading the article and for sharing the FB link with a git ignore example - the contents of the example file is not long because it doesn't have every dev tool possible, so I think you proved my point - so thank you :)
This is bad advice. The repo’s ignore file is there so that other people (without certain domain knowledge) don’t accidentally commit undesirable files, including directories containing sensitive information (which get generated by some tools like Terraform). Use the repo’s ignore, not your own.
Exactly, sometimes it takes me some minutes of research to determine whether a certain file should be ignored or not. In that situation, it's very appropriate to put that in the repo's gitignore, preferably with comments explaining why the pattern is included/excluded.