6 ms·

Stop Using Git Ignore

14 points by eddiejaoude 2y ago

deleted 2y ago
[deleted]
nullindividual 2y ago
You'd still need a repository .gitignore, more-so if you're not working in a professional development shop (i.e., SMB/enterprise IT) or open source project. There don't seem to be any downsides to a long .gitignore. Who cares if it is 100 or 1000 lines? Kind of pointless, in my view. I think a user-global .gitignore is fine to have to make sure you don't make mistakes for net-new projects or projects where someone forgot to add your exclusions, but otherwise, you're going to need both if you choose to use a user-global.
- eddiejaoude 2y ago
  yes we still need the repo git ignore for specific items for the repo it was more about stop using the repo git ignore for everything, rather than not use it at all
  - littlestymaar 2y ago
    Yeah, people putting MacOS-specific files that have no relation to the codebase in the .gitignore should stop.
    - eddiejaoude 2y ago
      yes exactly! then we end up with every IDE, operating system and dev tools (which is a lot)
      - gamepsys 2y ago
        Why is it a problem to have a long .gitignore?
        littlestymaar 2y ago
        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 issue and not the first?
        xboxnolifes 2y ago
        Because a dev's IDE project file can differ between every other dev, so committing it doesn't make sense. On the other hand, adding it to the .gitignore solves the problem of having differing config files.
        littlestymaar 2y ago
        But why is a “config file” (which is usually no more than a few dozen bytes) a problem? If you agree to add the name of the file in your .gitignore, why do you even bother to ignore it in the first place. It pollutes the .gitignore file as much as it pollutes the root directory…
        gamepsys 2y ago
        The first issue helps to prevent the second issue. Many projects will need to have a .gitignore to ignore build files or package artifacts. Adding to an existing file is preferable to adding additional files. Adding IDE level configs can override config files for other developers. The .gitignore does not have this negative impact on others.
        littlestymaar 2y ago
        But adding it to the developer's machine is preferable to both!
        Brian_K_White 2y ago
    - aniforprez 2y ago
      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.
- WCSTombs 2y ago
  Yeah, the article's point is also that you need both: > The contents of the repo’s git ignore is for the project only files and folders. Developers can customise their own global git ignore with extra exclusions they need. The two gitignores are for different purposes. The user-specific gitignore (~/.gitignore, or ~/.config/git/ignore) is tailored to the developer's specific workflow and preferred tools, so for example, a Vim user would have different rules from an Emacs or VSCode user. The project-level gitignore(s) are for build products. For example, if the project's build scripts create a "build" directory for all the build products, "build/" would probably be in the project's .gitignore. It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project.
  - nullindividual 2y ago
    > It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project. Why not? What's the harm? There seems to be zero significant downsides to include editor or operating system-specific patterns in the project .gitignore. A long .gitignore doesn't cause performance issues. To wit, you'll ultimately have someone without a global .gitignore that will lead to PR cleanup (or worse, direct commits). The project level .gitignore prevents mistakes by all committers. This is superior to trusting a developer correctly set up their own .gitignore. I think this is getting to the level of "optimization" because it feels good rather than doing any true good.
forrestthewoods 2y ago
Disagree. Many projects may want to commit IDE files. Ignoring them globally is simply wrong.
- eddiejaoude 2y ago
  oh wow, really! why? sounds like a horrible project, imagine those git conflicts can you elaborate on why they would want to commit IDE generated files? I have only seen this in legacy projects what happens if people want to use different IDEs?
  - Retr0id 2y ago
    IDE-specific files aren't necessarily auto-generated. They might include project-specific configs (random examples that come to mind include linter configs, tab/space indent settings, C library include paths)
  - S04dKHzrKT 2y ago
    Jetbrains' .DotSettings file is a specific example. It contains things like project specific dictionaries for the IDE's spell checker.
  - forrestthewoods 2y ago
    > imagine those git conflicts Not an issue > why they would want to commit IDE generated files You added the word generated. Many Windows-oriented projects a Visual Studio .sln file. This is great! You can open the sln, build, and run. It “just works”. Very nice. I wish more projects did this. > what happens if people want to use different IDEs? That’s fine. Nothing stopping it.
- WCSTombs 2y ago
  Once they're committed into the repository, they're no longer ignored, so what's the problem? The IDE files being listed in a hypothetical developer's global .gitignore do no harm in this case.
  - 2y ago
efilife 2y ago
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 bad thing? The author just wanted to rant about something but didn't know about what *[0] https://github.com/facebook/facebook-ios-sdk/blob/main/.gitignore https://github.com/facebook/facebook-ios-sdk/blob/main/.giti...
- eddiejaoude 2y ago
  I don't like to rant, I like to have professional discussions. 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 :)
  - efilife 2y ago
    Can you answer the questions?
    - eddiejaoude 2y ago
      >> Everyone uses different operating systems, IDEs and dev tools. > How is this related to .gitignore? Exactly! I explained in the article (and video) people fill the repo git ignore with all their personal tools that generate files, for example .DS_Store, .Idea etc. This should go in their personal global git ignore >> 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? Have a look at some other projects. I explained in the article (and video) the file can be pages long with every possible combination and will only keep growing as new dev tools come out >> 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 bad thing? As I explained in the article, it becomes a lot of work for the maintainers, to review, check for duplicate entries etc
gwynforthewyn 2y ago
Being honest, I dislike the tone of this sort of clickbaity rephrasing of the article title. The actual title is "You must use your Global Git Ignore!" which is completely true; the nuanced observation from the article "Using the git ignore feature is great but it has limitations, which is why I think this file is overused and often incorrectly" is a worthwhile hook, and presented thoughtfully. The title "Stop Using Git Ignore", which the author of the blog post chose for this submission, doesn't represent his actual article well, though it probably gets more upvotes on Hacker News. I wish he'd presented the article more accurately, as it's a worthwhile observation that, for example, we probably have so many .DS_Store files and .vscode/.idea directories that defining them once will save us some hassle.
- eddiejaoude 2y ago
  Thank you for the detailed feedback, I really appreciate you taking the time and effort. Yes the title is a little bit controversial
  - gwynforthewyn 2y ago
    Thanks for taking the time to write the article! We need more people sharing their good ideas like this.
    - eddiejaoude 2y ago
      Thank you! I like to think of my articles and youtube videos as a starting point for discussion - even after 15+ years I am still learning
  - phatskat 2y ago
    It’s more than “a little bit controversial”, it _is_ clickbait. If your title was more true to the article’s actual premise, I doubt you’d have as much engagement. The title made me click immediately because “wow that’s a wild opinion!” I opened the article and was greeted with a much more nuanced view than I was led to believe and tbh I likely wouldn’t have read it if the title was more accurate.
wobblyasp 2y ago
I'd rather enforce it at the repo then hope and pray everyone updates their global configs. Easy enough to catch but you'll miss some. Literally no cost to adding it to repo config either
- eddiejaoude 2y ago
  yes as an open source maintainer, this is a difficult decision I need to make for each project. On one hand, I want to do the right thing, but on the other, the initial convenience does come into play - but this can come back to bite us later when people play the green square game on the git ignore file in the GitHub repo
yodon 2y ago
Everyone is free to pick a proverbial hill to die on. Some focus on battles they are likely to win, others on battles they are bound to lose.
- eddiejaoude 2y ago
  not sure what you mean by this, can you explain more?
dvt 2y ago
This seems like a terrible idea.. imagine framework A that has a throwaway folder called ".blah"—now imagine framework B that has a very important configuration folder called ".blah"—so at best this would only cover IDE and OS stuff. But that stuff ends up being like what, 10 lines at most?
- eddiejaoude 2y ago
  I am suggesting we separate project specific and developer specific git ignores - I don't think you read the article
vegetablepotpie 2y ago
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 don’t want to see in an enterprise environment is someone checking in a 100MB binary file that gets checked into dev because the team was busy and approved a PR hastily. What would be helpful is a git hook that checks the mime type of a file and decide if it should even by a type of file that should be checked into a project.
- eddiejaoude 2y ago
  thank you for your detailed replied. The Git hook is an interesting idea, I use Git Husky for git hooks, and checking the mime type could be good to avoid files like screenshots being committed I will look into this idea. Thanks again
hbogert 2y ago
not sure I agree with the article or not, just wanted to state there's a third option: you can define your ignore rules per project but not necessarily share the, by putting the ignore rules in: .git/info/exclude
- eddiejaoude 2y ago
  Oh interesting 3rd option! Thank you for sharing, I will explore the practically side to this option and feedback. Thank you!
Lws803 2y ago
Ignoring .env files globally could prevent some mistakes.. :D
- eddiejaoude 2y ago
  yes exactly
htk 2y ago
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.
- eddiejaoude 2y ago
  Sorry you thought it was a trick, I guess I could have extended the title with "...for your personal files"
  - htk 2y ago
    Thank you for the reply. I believe you have interesting enough material to not need to resort to controversial titles. Keep writing, it'll only get better.
    - eddiejaoude 2y ago
      > I believe you have interesting enough material thank you, that means a lot to me! I really appreciate the feedback and support
deleted 2y ago
[deleted]
default-kramer 2y ago
> As a maintainer, don’t fall into the trap of putting every possible exclusion into the repo’s git ignore. This really is a “sticky plaster” approach in my view. What we should try to do is up-skill and educate the community, so it benefits everyone in the long run. Strong disagree. Please do continue trying to educate the community, but that's no reason to take the guardrails off.
- eddiejaoude 2y ago
  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 with unwanted files though, which will be painful for contributors and maintainers, but could be a good lesson?
  - default-kramer 2y ago
    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.)
    - eddiejaoude 2y ago
      I think as a solo maintainer on a project and getting many github notifications (and DMs about the notification) for their PRs every day, it had a negative effect on me.
jmclnx 2y ago
>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 :)
- eddiejaoude 2y ago
  Interesting to hear about your workflow! Someone else mentioned "./.git/info/exclude". It is something I will look in to and ask around to see who else uses it. Thanks for your comment
ghusto 2y ago
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.
- default-kramer 2y ago
  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.
  - eddiejaoude 2y ago
    good point, comments are super important
- eddiejaoude 2y ago
  I don't think you read the article, there is a video at the end if you prefer. 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
  - default-kramer 2y ago
    > Examples of folders included in the git ignore file are generated files like “.next” from NextJS or “test-results” from Playwright. These will be generated for every developer on the project regardless of their OS, IDE etc. > Yes I am saying this is wrong… (let me know if you agree/disagree below) I didn't realize that the first paragraph is saying "This is good"; I thought the second paragraph was saying that the first paragraph is bad.
    - eddiejaoude 2y ago
      oh sorry for the confusion! I do think we need both git ignores, but to be used appropriately. System global .gitignore solves a problem specific to that developer Repo .gitignore solves a problem for the project (and every developer)
TrianguloY 2y ago
Just a quick mention to remind that .gitignore files can be placed in any folder/subfolder inside a repository, and they will refer to folders inside itself only. The global .gitignore should be used for global rules and root folders, but if you have path with more than one folder on it, you may want to add it to a .gitignore inside that subfolder itself. Almost mandatory for monorepos too!
- eddiejaoude 2y ago
  Great point! Thank you for adding that, yes it works for sub folders also, which makes sense especially for mono repos I really appreciate you adding value to the conversation, thank you!
kennu 2y ago
It would be very inconvenient to try to synchronize global gitignore settings to all my computers and development environments. When .gitignore files are part of the project, they are automatically distributed everywhere where they are needed.
- eddiejaoude 2y ago
  > they are automatically distributed everywhere where they are needed for you and your tools, but what about everyone else? Look at using dotfiles to sync your computer's config to multiple computers, it is a great tool
  - kennu 2y ago
    Other people working on the project add their ignored files to the same .gitignore. No problem.
    - thiht 2y ago
      I don't understand why people make an issue of that. Just add everything that needs to be ignored to the .gitignore, as long as it makes sense to someone. If I use XYZ-Obscure-Unknown-Editor, just let me add `.xyz-obscure-unknown-editor/` to the .gitignore. It literally has no negative impact on anyone. There's no reason to gatekeep what goes to the .gitignore

14 points by eddiejaoude 2y ago

deleted 2y ago

[deleted]

You'd still need a repository .gitignore, more-so if you're not working in a professional development shop (i.e., SMB/enterprise IT) or open source project. There don't seem to be any downsides to a long .gitignore. Who cares if it is 100 or 1000 lines? Kind of pointless, in my view. I think a user-global .gitignore is fine to have to make sure you don't make mistakes for net-new projects or projects where someone forgot to add your exclusions, but otherwise, you're going to need both if you choose to use a user-global.

eddiejaoude 2y ago
yes we still need the repo git ignore for specific items for the repo it was more about stop using the repo git ignore for everything, rather than not use it at all
- littlestymaar 2y ago
  Yeah, people putting MacOS-specific files that have no relation to the codebase in the .gitignore should stop.
  - eddiejaoude 2y ago
    yes exactly! then we end up with every IDE, operating system and dev tools (which is a lot)
    - gamepsys 2y ago
      Why is it a problem to have a long .gitignore?
      - littlestymaar 2y ago
        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 issue and not the first?
        xboxnolifes 2y ago
        Because a dev's IDE project file can differ between every other dev, so committing it doesn't make sense. On the other hand, adding it to the .gitignore solves the problem of having differing config files.
        littlestymaar 2y ago
        But why is a “config file” (which is usually no more than a few dozen bytes) a problem? If you agree to add the name of the file in your .gitignore, why do you even bother to ignore it in the first place. It pollutes the .gitignore file as much as it pollutes the root directory…
        gamepsys 2y ago
        The first issue helps to prevent the second issue. Many projects will need to have a .gitignore to ignore build files or package artifacts. Adding to an existing file is preferable to adding additional files. Adding IDE level configs can override config files for other developers. The .gitignore does not have this negative impact on others.
        littlestymaar 2y ago
        But adding it to the developer's machine is preferable to both!
      - Brian_K_White 2y ago
  - aniforprez 2y ago
    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.
WCSTombs 2y ago
Yeah, the article's point is also that you need both: > The contents of the repo’s git ignore is for the project only files and folders. Developers can customise their own global git ignore with extra exclusions they need. The two gitignores are for different purposes. The user-specific gitignore (~/.gitignore, or ~/.config/git/ignore) is tailored to the developer's specific workflow and preferred tools, so for example, a Vim user would have different rules from an Emacs or VSCode user. The project-level gitignore(s) are for build products. For example, if the project's build scripts create a "build" directory for all the build products, "build/" would probably be in the project's .gitignore. It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project.
- nullindividual 2y ago
  > It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project. Why not? What's the harm? There seems to be zero significant downsides to include editor or operating system-specific patterns in the project .gitignore. A long .gitignore doesn't cause performance issues. To wit, you'll ultimately have someone without a global .gitignore that will lead to PR cleanup (or worse, direct commits). The project level .gitignore prevents mistakes by all committers. This is superior to trusting a developer correctly set up their own .gitignore. I think this is getting to the level of "optimization" because it feels good rather than doing any true good.

forrestthewoods 2y ago

Disagree. Many projects may want to commit IDE files. Ignoring them globally is simply wrong.

eddiejaoude 2y ago
oh wow, really! why? sounds like a horrible project, imagine those git conflicts can you elaborate on why they would want to commit IDE generated files? I have only seen this in legacy projects what happens if people want to use different IDEs?
- Retr0id 2y ago
  IDE-specific files aren't necessarily auto-generated. They might include project-specific configs (random examples that come to mind include linter configs, tab/space indent settings, C library include paths)
- S04dKHzrKT 2y ago
  Jetbrains' .DotSettings file is a specific example. It contains things like project specific dictionaries for the IDE's spell checker.
- forrestthewoods 2y ago
  > imagine those git conflicts Not an issue > why they would want to commit IDE generated files You added the word generated. Many Windows-oriented projects a Visual Studio .sln file. This is great! You can open the sln, build, and run. It “just works”. Very nice. I wish more projects did this. > what happens if people want to use different IDEs? That’s fine. Nothing stopping it.
WCSTombs 2y ago
Once they're committed into the repository, they're no longer ignored, so what's the problem? The IDE files being listed in a hypothetical developer's global .gitignore do no harm in this case.
- 2y ago

efilife 2y ago

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 bad thing? The author just wanted to rant about something but didn't know about what *[0] https://github.com/facebook/facebook-ios-sdk/blob/main/.gitignore https://github.com/facebook/facebook-ios-sdk/blob/main/.giti...

eddiejaoude 2y ago
I don't like to rant, I like to have professional discussions. 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 :)
- efilife 2y ago
  Can you answer the questions?
  - eddiejaoude 2y ago
    >> Everyone uses different operating systems, IDEs and dev tools. > How is this related to .gitignore? Exactly! I explained in the article (and video) people fill the repo git ignore with all their personal tools that generate files, for example .DS_Store, .Idea etc. This should go in their personal global git ignore >> 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? Have a look at some other projects. I explained in the article (and video) the file can be pages long with every possible combination and will only keep growing as new dev tools come out >> 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 bad thing? As I explained in the article, it becomes a lot of work for the maintainers, to review, check for duplicate entries etc

gwynforthewyn 2y ago

Being honest, I dislike the tone of this sort of clickbaity rephrasing of the article title. The actual title is "You must use your Global Git Ignore!" which is completely true; the nuanced observation from the article "Using the git ignore feature is great but it has limitations, which is why I think this file is overused and often incorrectly" is a worthwhile hook, and presented thoughtfully. The title "Stop Using Git Ignore", which the author of the blog post chose for this submission, doesn't represent his actual article well, though it probably gets more upvotes on Hacker News. I wish he'd presented the article more accurately, as it's a worthwhile observation that, for example, we probably have so many .DS_Store files and .vscode/.idea directories that defining them once will save us some hassle.

eddiejaoude 2y ago
Thank you for the detailed feedback, I really appreciate you taking the time and effort. Yes the title is a little bit controversial
- gwynforthewyn 2y ago
  Thanks for taking the time to write the article! We need more people sharing their good ideas like this.
  - eddiejaoude 2y ago
    Thank you! I like to think of my articles and youtube videos as a starting point for discussion - even after 15+ years I am still learning
- phatskat 2y ago
  It’s more than “a little bit controversial”, it _is_ clickbait. If your title was more true to the article’s actual premise, I doubt you’d have as much engagement. The title made me click immediately because “wow that’s a wild opinion!” I opened the article and was greeted with a much more nuanced view than I was led to believe and tbh I likely wouldn’t have read it if the title was more accurate.

wobblyasp 2y ago

I'd rather enforce it at the repo then hope and pray everyone updates their global configs. Easy enough to catch but you'll miss some. Literally no cost to adding it to repo config either

eddiejaoude 2y ago
yes as an open source maintainer, this is a difficult decision I need to make for each project. On one hand, I want to do the right thing, but on the other, the initial convenience does come into play - but this can come back to bite us later when people play the green square game on the git ignore file in the GitHub repo

yodon 2y ago

Everyone is free to pick a proverbial hill to die on. Some focus on battles they are likely to win, others on battles they are bound to lose.

eddiejaoude 2y ago
not sure what you mean by this, can you explain more?

dvt 2y ago

This seems like a terrible idea.. imagine framework A that has a throwaway folder called ".blah"—now imagine framework B that has a very important configuration folder called ".blah"—so at best this would only cover IDE and OS stuff. But that stuff ends up being like what, 10 lines at most?

eddiejaoude 2y ago
I am suggesting we separate project specific and developer specific git ignores - I don't think you read the article

vegetablepotpie 2y ago

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 don’t want to see in an enterprise environment is someone checking in a 100MB binary file that gets checked into dev because the team was busy and approved a PR hastily. What would be helpful is a git hook that checks the mime type of a file and decide if it should even by a type of file that should be checked into a project.

eddiejaoude 2y ago
thank you for your detailed replied. The Git hook is an interesting idea, I use Git Husky for git hooks, and checking the mime type could be good to avoid files like screenshots being committed I will look into this idea. Thanks again

hbogert 2y ago

not sure I agree with the article or not, just wanted to state there's a third option: you can define your ignore rules per project but not necessarily share the, by putting the ignore rules in: .git/info/exclude

eddiejaoude 2y ago
Oh interesting 3rd option! Thank you for sharing, I will explore the practically side to this option and feedback. Thank you!

Lws803 2y ago

Ignoring .env files globally could prevent some mistakes.. :D

eddiejaoude 2y ago
yes exactly

htk 2y ago

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.

eddiejaoude 2y ago
Sorry you thought it was a trick, I guess I could have extended the title with "...for your personal files"
- htk 2y ago
  Thank you for the reply. I believe you have interesting enough material to not need to resort to controversial titles. Keep writing, it'll only get better.
  - eddiejaoude 2y ago
    > I believe you have interesting enough material thank you, that means a lot to me! I really appreciate the feedback and support

deleted 2y ago

[deleted]

default-kramer 2y ago

> As a maintainer, don’t fall into the trap of putting every possible exclusion into the repo’s git ignore. This really is a “sticky plaster” approach in my view. What we should try to do is up-skill and educate the community, so it benefits everyone in the long run. Strong disagree. Please do continue trying to educate the community, but that's no reason to take the guardrails off.

eddiejaoude 2y ago
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 with unwanted files though, which will be painful for contributors and maintainers, but could be a good lesson?
- default-kramer 2y ago
  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.)
  - eddiejaoude 2y ago
    I think as a solo maintainer on a project and getting many github notifications (and DMs about the notification) for their PRs every day, it had a negative effect on me.

jmclnx 2y ago

>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 :)

eddiejaoude 2y ago
Interesting to hear about your workflow! Someone else mentioned "./.git/info/exclude". It is something I will look in to and ask around to see who else uses it. Thanks for your comment

ghusto 2y ago

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.

default-kramer 2y ago
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.
- eddiejaoude 2y ago
  good point, comments are super important
eddiejaoude 2y ago
I don't think you read the article, there is a video at the end if you prefer. 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
- default-kramer 2y ago
  > Examples of folders included in the git ignore file are generated files like “.next” from NextJS or “test-results” from Playwright. These will be generated for every developer on the project regardless of their OS, IDE etc. > Yes I am saying this is wrong… (let me know if you agree/disagree below) I didn't realize that the first paragraph is saying "This is good"; I thought the second paragraph was saying that the first paragraph is bad.
  - eddiejaoude 2y ago
    oh sorry for the confusion! I do think we need both git ignores, but to be used appropriately. System global .gitignore solves a problem specific to that developer Repo .gitignore solves a problem for the project (and every developer)

TrianguloY 2y ago

Just a quick mention to remind that .gitignore files can be placed in any folder/subfolder inside a repository, and they will refer to folders inside itself only. The global .gitignore should be used for global rules and root folders, but if you have path with more than one folder on it, you may want to add it to a .gitignore inside that subfolder itself. Almost mandatory for monorepos too!

eddiejaoude 2y ago
Great point! Thank you for adding that, yes it works for sub folders also, which makes sense especially for mono repos I really appreciate you adding value to the conversation, thank you!

kennu 2y ago

It would be very inconvenient to try to synchronize global gitignore settings to all my computers and development environments. When .gitignore files are part of the project, they are automatically distributed everywhere where they are needed.

eddiejaoude 2y ago
> they are automatically distributed everywhere where they are needed for you and your tools, but what about everyone else? Look at using dotfiles to sync your computer's config to multiple computers, it is a great tool
- kennu 2y ago
  Other people working on the project add their ignored files to the same .gitignore. No problem.
  - thiht 2y ago
    I don't understand why people make an issue of that. Just add everything that needs to be ignored to the .gitignore, as long as it makes sense to someone. If I use XYZ-Obscure-Unknown-Editor, just let me add `.xyz-obscure-unknown-editor/` to the .gitignore. It literally has no negative impact on anyone. There's no reason to gatekeep what goes to the .gitignore