7 ms·

I heavily advise AGAINST using this for anything apart from OS level file spam (.DS_Store etc). We spent a good part of a day rebuilding a repo after a junior

I heavily advise AGAINST using this for anything apart from OS level file spam (.DS_Store etc). We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project. Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...

sitzkrieg 4y ago
how did that project ever build on ci :)
- 89vision 4y ago
  but it worked on my machine
  - abustamam 4y ago
    Ship your machine as CI, problem solved /s
    - rubyist5eva 4y ago
      docker wants to know your location
- xyst 4y ago
  hint: there was no CI
  - superjan 4y ago
    I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.
- TheSoftwareGuy 4y ago
  Probably the dev made the code review before leaving
runarberg 4y ago
You might have learned the wrong lesson. A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc. Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations. Also don’t code review the code it self, review the diff.
- nullgeo 4y ago
  Yeah exactly, if I `require important.rb` in this file, and `important.rb` wasn't committed how did that project even build and get deployed. Any sane build system will instantly fail for this situations. Looks like an issue with dev ops/engineering culture rather than .gitignore
- someweirdperson 4y ago
  >Also don’t code review the code it self, review the diff. A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.
bmitc 4y ago
Telling developers to not use the global .gitignore seems to be the wrong response. For example, I use VS Code, its extensions, and various other development tools that create local files that should not be in repositories. Those files and directories do not belong in a repository's .gitignore file, unless it's a personal project. They most often belong in a global .gitignore unless a team uses a common set of tools. Having a single developer's custom tools be handled by a repository's .gitignore seems to be the wrong approach.
- Fatnino 4y ago
  .git/info/exclude seems like the right place for this.
  - bmitc 4y ago
    That's only per repository, isn't it? It won't really be convenient when you're working across several repositories or languages.
fishywang 4y ago
If they did not commit all the important files and your CI system didn't catch that, that's definitely the fault of your CI system, not global gitignore.
- tehbeard 4y ago
  Because there isn't a CI? Shocking I know /s. But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...
  - Dobbs 4y ago
    You don’t have to be at a tech startup to have things like CI and/or code review platforms.
- aynawn 4y ago
  Agreed. If the code is in GitHub, it's incredibly easy to create a simple github actions workflow that could run the app.
- llllllllllll9 4y ago
  so glad i don't work with you.
  - xxpor 4y ago
    Why? They're right imo
    - llllllllllll9 4y ago
      fishywang's attitude
      - SZJX 4y ago
        What attitude lmao. They’re very matter-of-fact in expressing an objective opinion from what I can see.

sitzkrieg 4y ago

how did that project ever build on ci :)

89vision 4y ago
but it worked on my machine
- abustamam 4y ago
  Ship your machine as CI, problem solved /s
  - rubyist5eva 4y ago
    docker wants to know your location
xyst 4y ago
hint: there was no CI
- superjan 4y ago
  I heavily advise AGAINST not using CI. If properly applied it solves .gitignore mistakes and many more, made by those infamous junior devs. On second thought, not just juniors. Oh well.
TheSoftwareGuy 4y ago
Probably the dev made the code review before leaving

runarberg 4y ago

You might have learned the wrong lesson. A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc. Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations. Also don’t code review the code it self, review the diff.

nullgeo 4y ago
Yeah exactly, if I `require important.rb` in this file, and `important.rb` wasn't committed how did that project even build and get deployed. Any sane build system will instantly fail for this situations. Looks like an issue with dev ops/engineering culture rather than .gitignore
someweirdperson 4y ago
>Also don’t code review the code it self, review the diff. A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.

bmitc 4y ago

Telling developers to not use the global .gitignore seems to be the wrong response. For example, I use VS Code, its extensions, and various other development tools that create local files that should not be in repositories. Those files and directories do not belong in a repository's .gitignore file, unless it's a personal project. They most often belong in a global .gitignore unless a team uses a common set of tools. Having a single developer's custom tools be handled by a repository's .gitignore seems to be the wrong approach.

Fatnino 4y ago
.git/info/exclude seems like the right place for this.
- bmitc 4y ago
  That's only per repository, isn't it? It won't really be convenient when you're working across several repositories or languages.

fishywang 4y ago

If they did not commit all the important files and your CI system didn't catch that, that's definitely the fault of your CI system, not global gitignore.

tehbeard 4y ago
Because there isn't a CI? Shocking I know /s. But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...
- Dobbs 4y ago
  You don’t have to be at a tech startup to have things like CI and/or code review platforms.
aynawn 4y ago
Agreed. If the code is in GitHub, it's incredibly easy to create a simple github actions workflow that could run the app.
llllllllllll9 4y ago
so glad i don't work with you.
- xxpor 4y ago
  Why? They're right imo
  - llllllllllll9 4y ago
    fishywang's attitude
    - SZJX 4y ago
      What attitude lmao. They’re very matter-of-fact in expressing an objective opinion from what I can see.