Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.gitignore Everything by Default

packagemain.tech

Post reply on HN
Print view View original

161–170 of 185 posts

Re: .gitignore Everything by Default

#161

Post by jeltz »

traviswingo wrote: post #50
rcfox wrote: post #10

This seems like bad advice. I've very rarely committed extra files by accident, but I would 100% forget to unignore files I meant to commit. If you're doing an initial setup step to gitignore everything, why not just do an initial setup step to gitignore the usual files? Make a template that you copy into all of your repos.

> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.

I do not think it is the right choice for any repository or developer. It just seems like terrible advice.

Re: .gitignore Everything by Default

#162

Post by hedora »

rcv wrote: post #147
grim_io wrote: post #80

Earlier quoted context omitted.

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.

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

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

Re: .gitignore Everything by Default

#163

Post by mckee_plus_plus »

Zambyte wrote: post #66
electrovir wrote: post #47

Earlier quoted context omitted.

For many years I've have a git-ignored ".not-committed" folder in all of my repos for throwing extra anything into. It's been a huge life saver!

You can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore

And then you have a known path to script up all your repos' stuff for backup

Re: .gitignore Everything by Default

#165

Post by yawaramin »

ozim wrote: post #101
yurishimo wrote: post #86

Earlier quoted context omitted.

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.

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 do…

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/

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!

Re: .gitignore Everything by Default

#167

Post by cush »

cortesoft wrote: post #76
cush wrote: post #17

Earlier quoted context omitted.

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

Re: .gitignore Everything by Default

#168

Post by blharr »

embedding-shape wrote: post #87
grim_io wrote: post #80

Earlier quoted context omitted.

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.

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

Git becomes a lot easier to understand once you learn its "hidden" interactive flags

Like git rebase -i as well

Re: .gitignore Everything by Default

#169

Post by singpolyma3 »

matijs wrote: post #124
singpolyma3 wrote: post #104

Better would be to ban both git add . And git commit -a

Ban `git add .` for sure, but what’s so bad about `git commit -a`? It only adds/removes what was already under version control.

Makes it easy to commit things you didn't expect without having reviewed them

Re: .gitignore Everything by Default

#170

Post by phire »

yurishimo wrote: post #86
kryptiskt wrote: post #81

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN