7 ms·

Most of the colleagues I've worked with only use "git add ." without checking first. Keys, npm directories and huge binaries are fixed by deleting them later o

by grim_io 11d ago

Most of the colleagues I've worked with only use "git add ." without checking first. Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.

kryptiskt 11d ago
The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
- yurishimo 11d ago
  In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
  - ozim 11d ago
    One problem I see all the time is that people are not using proper tools. Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs. Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging. People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer. I recommend looking here: https://git-scm.com/tools/guis https://git-scm.com/tools/guis (it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)
    - nuancebydefault 11d ago
      I guess your being downvoted around not being in favor of CLI is typical at HN...
    - yawaramin 11d ago
      You’re not wrong. I’ve used tig, a git TUI that renders very nice views of the diffs, for many years: https://jonas.github.io/tig/ https://jonas.github.io/tig/ Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!
  - phire 11d ago
    If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right? But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.
- godelski 11d ago
  It's at least easy to fix. Not pushing a file has a much easier fix than pushing an API key. The damage is also very different. Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions
- Tuna-Fish 11d ago
  That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens. It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.
embedding-shape 11d ago
> Most of the colleagues I've worked with only use "git add ." without checking first. I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.
- blharr 11d ago
  Git becomes a lot easier to understand once you learn its "hidden" interactive flags Like git rebase -i as well
agentdev001 11d ago
Secrets shouldn't be plain text in project directory >:[
tyre 11d ago
> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror. Keys that are deleted are not gone from the git history. They’re still in the repo. Same with giant blobs and binaries.
- ianmcgowan 11d ago
  That's the horror..
rcv 11d ago
Genuinely curious - do you all not have a code review process, or do the reviewers just not care?
- hedora 11d ago
  Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.

by grim_io 11d ago

Most of the colleagues I've worked with only use "git add ." without checking first. Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.

kryptiskt 11d ago

The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.

yurishimo 11d ago
In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
- ozim 11d ago
  One problem I see all the time is that people are not using proper tools. Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs. Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging. People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer. I recommend looking here: https://git-scm.com/tools/guis https://git-scm.com/tools/guis (it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)
  - nuancebydefault 11d ago
    I guess your being downvoted around not being in favor of CLI is typical at HN...
  - yawaramin 11d ago
    You’re not wrong. I’ve used tig, a git TUI that renders very nice views of the diffs, for many years: https://jonas.github.io/tig/ https://jonas.github.io/tig/ Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!
- phire 11d ago
  If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right? But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.
godelski 11d ago
It's at least easy to fix. Not pushing a file has a much easier fix than pushing an API key. The damage is also very different. Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions
Tuna-Fish 11d ago
That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens. It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.

embedding-shape 11d ago

> Most of the colleagues I've worked with only use "git add ." without checking first. I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.

blharr 11d ago
Git becomes a lot easier to understand once you learn its "hidden" interactive flags Like git rebase -i as well

agentdev001 11d ago

Secrets shouldn't be plain text in project directory >:[

tyre 11d ago

> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror. Keys that are deleted are not gone from the git history. They’re still in the repo. Same with giant blobs and binaries.

ianmcgowan 11d ago
That's the horror..

rcv 11d ago

Genuinely curious - do you all not have a code review process, or do the reviewers just not care?

hedora 11d ago
Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.