3 ms·

> what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? Our CI. And code review is what prevents .DS_Store to be added

by pilif 4y ago

> what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? Our CI. And code review is what prevents .DS_Store to be added to .gitignore. And, again, I'm saying this as a purist with a developer team of 99% Mac users.

dymk 4y ago
So now you leak that kludge into CI, and waste code review cycles, when it could have just been in .gitignore
9dev 4y ago
If anyone on my team even dared to waste time on this discussion, let alone add CI checks or instruct the team about putting the exclude from A to B, we’d had a serious conversation about generating business value, cargo culting, and the purpose of code in general. Fascinating.
- lobstrosity420 4y ago
  This is why it’s important to do a culture fit evaluation on top of a technical evaluation. An unpopular opinion here for sure.
- danielhep 4y ago
  [flagged]
- pilif 4y ago
  Some of the repos we work on date back to 2004 (going from CSV to Subversion, to git. Developers moving from mostly Windows to mostly Linux, to mostly macOS). If everybody was free to check in debris of whatever IDE and/or OS they were working at any given time, the codebase would be a terrible mess, especially as such debris tends to go unnoticed for ages until it's not. Just like we have CI checks to make sure nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards. All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one. Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.
  - 9dev 4y ago
    You're moving the goal posts here. We're not discussing not checking in debris like `.DS_Store` files; I'm totally on board with that, but that's covered in any .gitignore template generated by my IDE. Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. And while you're free to play holier-than-thou at your job as you like, I'd give hell to anyone wasting my team's time like that.
    - hnlmorg 4y ago
      There’s also an argument for having every exclusion centralised in one config file (ie gitignore) with regards to making it easier to review what exclusions are active. As a DevOps guy (but with 30 years of experience in development too), one of my pet peeves is having to deal with a thousand different edge cases because someone decided that intellectual cleverness was more important than a holistic approach to design and architecture.
    - alxlaz 4y ago
      > Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs and current implementations, rather than the myriad of alternate practices that software shops everywhere devise. I've done migrations like these before -- while the parent poster may be doing all that for the wrong reasons (puritanism) they are absolutely right to do them.
      - 9dev 4y ago
        So, just to be clear, when migrating from git to a hypothetical new VCS, you're saying that it will be beneficial to have exclusion rules for some files in the repository, and for others locally on every developer's machine, hopefully? The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it. If that breaks your new VCS, maybe migrating to it isn't such a good idea?
imiric 4y ago
I think a single line in the repo's .gitignore file hurts nobody, while adding CI checks, or catching it in a code review just wastes everyone's time. Expecting everyone to configure their repos precisely is asking too much, IMO. I've seen all kinds of filters in a .gitignore for programs I don't personally use. I don't mind it at all.
- account42 4y ago
  Or you could just set it once per developer in their core.excludesFile and have it apply to all repos.
  - 9dev 4y ago
    Let's see. Either we spend 8 seconds adding it to the project .gitignore, once in the lifetime of the project; or we spend 15 minutes instructing everyone on the team, plus once for every new hire, so they can spend another 30 seconds on modifying their local configuration. I'm pretty sure I'll never create so many new projects in my entire career that those 8 seconds would add up to the amount of time required to follow your suggestion. Be a little more pragmatic, folks!

by pilif 4y ago

dymk 4y ago

So now you leak that kludge into CI, and waste code review cycles, when it could have just been in .gitignore

9dev 4y ago

If anyone on my team even dared to waste time on this discussion, let alone add CI checks or instruct the team about putting the exclude from A to B, we’d had a serious conversation about generating business value, cargo culting, and the purpose of code in general. Fascinating.

lobstrosity420 4y ago
This is why it’s important to do a culture fit evaluation on top of a technical evaluation. An unpopular opinion here for sure.
danielhep 4y ago
[flagged]
pilif 4y ago
Some of the repos we work on date back to 2004 (going from CSV to Subversion, to git. Developers moving from mostly Windows to mostly Linux, to mostly macOS). If everybody was free to check in debris of whatever IDE and/or OS they were working at any given time, the codebase would be a terrible mess, especially as such debris tends to go unnoticed for ages until it's not. Just like we have CI checks to make sure nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards. All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one. Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.
- 9dev 4y ago
  You're moving the goal posts here. We're not discussing not checking in debris like `.DS_Store` files; I'm totally on board with that, but that's covered in any .gitignore template generated by my IDE. Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. And while you're free to play holier-than-thou at your job as you like, I'd give hell to anyone wasting my team's time like that.
  - hnlmorg 4y ago
    There’s also an argument for having every exclusion centralised in one config file (ie gitignore) with regards to making it easier to review what exclusions are active. As a DevOps guy (but with 30 years of experience in development too), one of my pet peeves is having to deal with a thousand different edge cases because someone decided that intellectual cleverness was more important than a holistic approach to design and architecture.
  - alxlaz 4y ago
    > Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs and current implementations, rather than the myriad of alternate practices that software shops everywhere devise. I've done migrations like these before -- while the parent poster may be doing all that for the wrong reasons (puritanism) they are absolutely right to do them.
    - 9dev 4y ago
      So, just to be clear, when migrating from git to a hypothetical new VCS, you're saying that it will be beneficial to have exclusion rules for some files in the repository, and for others locally on every developer's machine, hopefully? The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it. If that breaks your new VCS, maybe migrating to it isn't such a good idea?

imiric 4y ago

I think a single line in the repo's .gitignore file hurts nobody, while adding CI checks, or catching it in a code review just wastes everyone's time. Expecting everyone to configure their repos precisely is asking too much, IMO. I've seen all kinds of filters in a .gitignore for programs I don't personally use. I don't mind it at all.

account42 4y ago
Or you could just set it once per developer in their core.excludesFile and have it apply to all repos.
- 9dev 4y ago
  Let's see. Either we spend 8 seconds adding it to the project .gitignore, once in the lifetime of the project; or we spend 15 minutes instructing everyone on the team, plus once for every new hire, so they can spend another 30 seconds on modifying their local configuration. I'm pretty sure I'll never create so many new projects in my entire career that those 8 seconds would add up to the amount of time required to follow your suggestion. Be a little more pragmatic, folks!