I'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.

I do that for my personal projects.

Doing that on projects where I collaborate I would equate to pissing in public.

That is also why pull requests are such a great idea in general, because GIT allows one to piss in his own garden as much as they want.

Even if I could piss in my own branch I never do so when working on a project with other people.

I don't piss around my home obviously in case someone didn't get the metaphor.

Now walk through exactly what would happen when those lazy people follow this approach…

You see the issue right?

I think the idea is that missing files will immediately cause issues (tests will fail, etc), so CI should catch this immediately.

Adding extra, sensitive, files would not cause test failures, and even if they do (via secret scanners, etc), it is too late at that point because they will have already been shared upstream.

I am not sure the juice is worth the squeeze here, but it has some logic to it.

I'd make completely different assumptions

> You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

I’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.

So the better alternative is for them to leave out files that should be committed?

I do this. What's wrong with this approach and how should it be done correctly?

Pay attention to what you are staging. Generally this means `git add -p` or similar.

Pay attention to what you are committing. Generally this means looking at what you have staged before writing your commit log message.

Pay attention to what is in your pull request. Generally this means looking at your commits / draft pull request before you ask for code review.

If anybody other than you sees crap in your pull request that should obviously have been ignored, it means you have failed to pay attention to what you are doing three separate times.

I do all of these three. I guess there's nothing wrong in this approach after all. It just boils down to "not push shitty commits"

Either you are paying attention or you are doing what the GP described in their comment. The two are mutually exclusive.

That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.

LLMs learned from people xD