I have never once experienced this problem. Mostly because I don't work with people who blindly commit everything without even looking once to see what's in their commit.
I use gitnr[1] to add fairly comprehensive `.gitignore` files to my repos at creation time.
Ultimately, it's the responsibility of each developer to determine whether or not the files they've added to their local clone really belong in source control! I've never encountered this issue, either, and I think I'd be unhappy working on a team where it was a serious problem.
That said, the whitelist approach does seem kinda interesting. It's really what should be present from the start, since Git had a manual staging process. But maybe this gap highlights a legit usabiiity issue. Maybe "add everything" plus an explicit, version-controlled whitelist is somehow easier or more intuitive than the "add nothing" default.
In the Go world, the whitelist approach is a popular alternative to the standard gitignore, since Go projects can kind of take any structure the developer sees fit.
To me the normal approach makes equal sense. I create a file, but I'm not ready for other people to see it yet, because it's just a placeholder. So I don't add it. But another set of files are ready, and are part of one logical step of the change, so I add them specifically and commit.
Interns and new hires sometimes need a quick chat about actually looking at their changes before asking for a review, but that's about it in my experience. I guess it could be a problem for a project which accepts a large number of public PRs from mostly non-technical or beginner users?
It's not a problem with PRs if you use Squash merge, the developer can make any number of changes to that PR but in the end, only the final version (in this case it doesn't include .DS_Store) will be commited. even the .DS_Store file will not be in the git index
Comments
I have never once experienced this problem. Mostly because I don't work with people who blindly commit everything without even looking once to see what's in their commit.
I use gitnr[1] to add fairly comprehensive `.gitignore` files to my repos at creation time.
Ultimately, it's the responsibility of each developer to determine whether or not the files they've added to their local clone really belong in source control! I've never encountered this issue, either, and I think I'd be unhappy working on a team where it was a serious problem.
That said, the whitelist approach does seem kinda interesting. It's really what should be present from the start, since Git had a manual staging process. But maybe this gap highlights a legit usabiiity issue. Maybe "add everything" plus an explicit, version-controlled whitelist is somehow easier or more intuitive than the "add nothing" default.
--
1: https://github.com/reemus-dev/gitnr
In the Go world, the whitelist approach is a popular alternative to the standard gitignore, since Go projects can kind of take any structure the developer sees fit.
To me the normal approach makes equal sense. I create a file, but I'm not ready for other people to see it yet, because it's just a placeholder. So I don't add it. But another set of files are ready, and are part of one logical step of the change, so I add them specifically and commit.
Interns and new hires sometimes need a quick chat about actually looking at their changes before asking for a review, but that's about it in my experience. I guess it could be a problem for a project which accepts a large number of public PRs from mostly non-technical or beginner users?
It's not a problem with PRs if you use Squash merge, the developer can make any number of changes to that PR but in the end, only the final version (in this case it doesn't include .DS_Store) will be commited. even the .DS_Store file will not be in the git index
That sacrifices the git history though. It turns the PR into a huge atomic change instead of a series of step-by-step changes that are easy to review.
Yes, I have run into that once or twice but never to the extent that I would call it "sisyphean", haha.
I had this issue all the time. Until I retired as a CS college professor. An accept-list is the way to go when you have lots of people making commits.