3 ms·

>This seems like bad advice. I've very rarely committed extra files by accident, [...] You clearly haven't seen the people who are lazy and so just do `git add

by gruez 1mo ago

>This seems like bad advice. I've very rarely committed extra files by accident, [...] 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.

cush 1mo ago
Now walk through exactly what would happen when those lazy people follow this approach… You see the issue right?
- cortesoft 1mo ago
  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.
  - cush 1mo ago
    I'd make completely different assumptions
rcfox 1mo ago
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.
JimDabell 1mo ago
> 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.
efilife 1mo ago
I do this. What's wrong with this approach and how should it be done correctly?
- JimDabell 1mo ago
  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.
  - efilife 1mo ago
    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"
    - JimDabell 1mo ago
      Either you are paying attention or you are doing what the GP described in their comment. The two are mutually exclusive.
jeremyjh 1mo ago
So the better alternative is for them to leave out files that should be committed?
godelski 1mo ago
> people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time. People? Even LLMs do that
- ozim 1mo ago
  LLMs learned from people xD
- ludwik 1mo ago
  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.
ozim 1mo ago
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.

by gruez 1mo ago

cush 1mo ago

Now walk through exactly what would happen when those lazy people follow this approach… You see the issue right?

cortesoft 1mo ago
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.
- cush 1mo ago
  I'd make completely different assumptions

rcfox 1mo ago

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.

JimDabell 1mo ago

> 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.

efilife 1mo ago

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

JimDabell 1mo ago
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.
- efilife 1mo ago
  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"
  - JimDabell 1mo ago
    Either you are paying attention or you are doing what the GP described in their comment. The two are mutually exclusive.

jeremyjh 1mo ago

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

godelski 1mo ago

> people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time. People? Even LLMs do that

ozim 1mo ago
LLMs learned from people xD
ludwik 1mo ago
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.

ozim 1mo ago

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.