Colour me confused, but isn't the clue in the title? The file has the word ignore in it, so one would presume that the file contains a list of things to ignore.
My second point of confusion, is why would anyone need to add anything to .gitignore when a new developer joins the team? The only example I can think of, is that they use a different IDE to everyone else, and they don't want to be pushing metadata for their IDE to VCS.
Since I'm a little confused, I went to check the documentation on git-scm.com. The very first sentence in the description says "A gitignore file specifies intentionally untracked files that Git should ignore. " - which to me, is the way I've always done it, but you're saying is a mistake? Did whomever wrote that document also make a mistake?
It seems to me, that the intent of the .gitignore file is indeed to be a blacklist.
Then, of course, comes the discussion about what files we should be staging (and even, what file parts) - source code, lives in VCS, period. If it isn't source code (or documentation tightly coupled with that source code), it has no business being in VCS and shouldn't be staged, let alone committed - or worse still, pushed.
Please do let me know why a new developer or new tool, should change the way we use .gitignore files. Examples would be awesome, because I've never seen it (save for, as I said, IDE differences).
His approach is probably safer. I accidentally commit files all the time that I would rather have excluded, and that's permanent.
Say I'm working on a video app, and I get it pumping out test video, I say "yay!", and commit my changes, only to discover in horror that I've also committed a bunch of test video. No, It shouldn't happen, but developers are people, we run on caffeine, and at the end of the day sometimes we're not 100%.
This would remedy that. I already do it with Docker to avoid accidental giant images. There are security considerations as well. Search GitHub for passwords sometime if you're curious.
Rewriting history breaks stuff, so I try to avoid that, and checklists are nice but it's still possible to miss stuff. As to what's intended, you are probably right, but I tend to prefer allowlists in general, so this is an approach I might consider in the future. I already do it with Python packaging, Docker and more, so why not?
The syntax is flexible enough to allow either, so I'm not sure there is any wrong way. I suppose it's mostly down to personal taste and philosophy.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Colour me confused, but isn't the clue in the title? The file has the word ignore in it, so one would presume that the file contains a list of things to ignore.
My second point of confusion, is why would anyone need to add anything to .gitignore when a new developer joins the team? The only example I can think of, is that they use a different IDE to everyone else, and they don't want to be pushing metadata for their IDE to VCS.
Since I'm a little confused, I went to check the documentation on git-scm.com. The very first sentence in the description says "A gitignore file specifies intentionally untracked files that Git should ignore. " - which to me, is the way I've always done it, but you're saying is a mistake? Did whomever wrote that document also make a mistake?
It seems to me, that the intent of the .gitignore file is indeed to be a blacklist.
Then, of course, comes the discussion about what files we should be staging (and even, what file parts) - source code, lives in VCS, period. If it isn't source code (or documentation tightly coupled with that source code), it has no business being in VCS and shouldn't be staged, let alone committed - or worse still, pushed.
Please do let me know why a new developer or new tool, should change the way we use .gitignore files. Examples would be awesome, because I've never seen it (save for, as I said, IDE differences).
His approach is probably safer. I accidentally commit files all the time that I would rather have excluded, and that's permanent.
Say I'm working on a video app, and I get it pumping out test video, I say "yay!", and commit my changes, only to discover in horror that I've also committed a bunch of test video. No, It shouldn't happen, but developers are people, we run on caffeine, and at the end of the day sometimes we're not 100%.
This would remedy that. I already do it with Docker to avoid accidental giant images. There are security considerations as well. Search GitHub for passwords sometime if you're curious.
There's nothing wrong with mistakes (such as committing the wrong thing), git has powerful history rewriting capabilities.
But really, you can add pre-commit hooks prompting you with checklists etc if you keep making mistakes.
My issue, is that the author suggests that using a tool in the manner that those who made it say you should, is somehow a mistake.
Rewriting history breaks stuff, so I try to avoid that, and checklists are nice but it's still possible to miss stuff. As to what's intended, you are probably right, but I tend to prefer allowlists in general, so this is an approach I might consider in the future. I already do it with Python packaging, Docker and more, so why not?
The syntax is flexible enough to allow either, so I'm not sure there is any wrong way. I suppose it's mostly down to personal taste and philosophy.