5 ms·

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. Th

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
        I'll trade you a question for a question. How can any coder or engineer or admin or tech of any stripe ask such a question? The problem is not that babies will die. Yet just because no babies will die and we can afford the disk space and it doesn't slow down the performance does not mean there is no reason. What's the problem in placing 50,000 redundant copies of 2,000 lines of config in every individual repo? Where to begin? 1 - my project has a particular kind of file I need to ignore. I either have to add it to the bottom of this huge file blindly, or I have to search the file every time before adding something, in case it's already in there somewhere. 2 - my project is mysteriously not working as expected because I didn't realize that somewhere in the huge mass of everyone else's ignores in the world that MY project has in it, there are some patterns that affect files I didn't expect or ask for and didn't realize I would have to specially override. 3 - the idea doesn't scale because the world is big and essentially every file name pattern needs to be ignored by someone somewhere, so if all possible ignores were copied to every repo, every file would be ignored in every repo. In that case we should not have gitignore, we should have gitinclude. If you think the answer to this is "just pick the common things" then you just broke your own theory that everything should be copied to all. 4 - If every repo has it's own copy of the database of all ignores, then every repo has it's own out of sync copy. If it doesn't matter that it goes out of sync, then it doesn't matter if it's in there at all in the first place. If it does matter, then how is it kept up to date? I have edited the stock initial copy with the stuff that's particular to my project. Shall we have git itself always doing a little side git operation just on this file against a central public reference every time? So every git add/status/commit etc aside from looking at the local and origin, also checks a special origin just for that file, so that I get a patch that updates my gitignore without simply replacing it? Maybe we split gitignore into 2 parts, a shared common global part and a project-specific part? Wow, what a great idea, why didn't git already work that way by default all along? 5 - Why stop at just one stupid copy of a database of stuff that doesn't apply per repo? If there is no harm in a redundant out of sync copy per repo, then there is no harm in a redundant out of sync copy per directory. "what's the problem?" Seriously what is the problem? Because it is the same exact answer for the repo as for the directory. This question is ridiculous unless you are new and have never tried to use any tools yet and are still unaware of even the most basic engineering principles in general, about anything not just git or software development. In that case, that is fair and everyone starts out as a child that has to find out everything the first time somehow. In that case the answer is "go ahead and see how it goes" because for some things if you don't understand the problem just by thinking about it and projecting implications for about 2 seconds, then no mere explaination will be convincing. Nothing I've said here was convincing right? You will just have to find out by being stupid for a while and actually run into all the little paper cuts in order to recognize that they exist and they suck and what the totally simple and obvious ways to avoid them are.
  - 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.

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
      I'll trade you a question for a question. How can any coder or engineer or admin or tech of any stripe ask such a question? The problem is not that babies will die. Yet just because no babies will die and we can afford the disk space and it doesn't slow down the performance does not mean there is no reason. What's the problem in placing 50,000 redundant copies of 2,000 lines of config in every individual repo? Where to begin? 1 - my project has a particular kind of file I need to ignore. I either have to add it to the bottom of this huge file blindly, or I have to search the file every time before adding something, in case it's already in there somewhere. 2 - my project is mysteriously not working as expected because I didn't realize that somewhere in the huge mass of everyone else's ignores in the world that MY project has in it, there are some patterns that affect files I didn't expect or ask for and didn't realize I would have to specially override. 3 - the idea doesn't scale because the world is big and essentially every file name pattern needs to be ignored by someone somewhere, so if all possible ignores were copied to every repo, every file would be ignored in every repo. In that case we should not have gitignore, we should have gitinclude. If you think the answer to this is "just pick the common things" then you just broke your own theory that everything should be copied to all. 4 - If every repo has it's own copy of the database of all ignores, then every repo has it's own out of sync copy. If it doesn't matter that it goes out of sync, then it doesn't matter if it's in there at all in the first place. If it does matter, then how is it kept up to date? I have edited the stock initial copy with the stuff that's particular to my project. Shall we have git itself always doing a little side git operation just on this file against a central public reference every time? So every git add/status/commit etc aside from looking at the local and origin, also checks a special origin just for that file, so that I get a patch that updates my gitignore without simply replacing it? Maybe we split gitignore into 2 parts, a shared common global part and a project-specific part? Wow, what a great idea, why didn't git already work that way by default all along? 5 - Why stop at just one stupid copy of a database of stuff that doesn't apply per repo? If there is no harm in a redundant out of sync copy per repo, then there is no harm in a redundant out of sync copy per directory. "what's the problem?" Seriously what is the problem? Because it is the same exact answer for the repo as for the directory. This question is ridiculous unless you are new and have never tried to use any tools yet and are still unaware of even the most basic engineering principles in general, about anything not just git or software development. In that case, that is fair and everyone starts out as a child that has to find out everything the first time somehow. In that case the answer is "go ahead and see how it goes" because for some things if you don't understand the problem just by thinking about it and projecting implications for about 2 seconds, then no mere explaination will be convincing. Nothing I've said here was convincing right? You will just have to find out by being stupid for a while and actually run into all the little paper cuts in order to recognize that they exist and they suck and what the totally simple and obvious ways to avoid them are.
- 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.