undefined | Better HN

0 pointscloseparen5y ago0 comments

Giving up "git add ." is a steep price. I prefer to store my secrets outside the working copy. Then when I cd into the working copy, direnv sets environment variables either pointing to or catting the files from my home directory. This works beautifully with Ansible Vault.

0 comments

jacoblambda5y ago

I'm curious why people use "git add ."? I don't see the convenience over "git add -i" and quickly reading through the items to add.

Realistically if you have a reasonable git workflow any add operation should only have a handful of files that you can quickly scan through to make sure nothing fishy is present and at most interactive mode adds a few seconds to the add process for you to read through everything.

Note: This is an entirely serious question and I am hoping for an answer. I promise I'm not trying to antagonise anyone. I just see so many people reaching for "add ." instead of "add -i".

closeparenOP5y ago

Keeping a file untracked is never what I want. Either it goes in the repo or it goes in .gitignore. My gitignores are usually comprehensive, and when they're not I'll catch it in my self-review of the PR.

jacoblambda5y ago

That's fair but isn't it more work to go back and have to rebase your commits to remove something that accidentally got skipped in your .gitignore?

I say this because I am also a firm believer of if it shouldn't be committed it should be in the .gitignore but I've only ever been burned by that when either myself or others weren't using interactive add.

Basically, isn't it easier to fix a .gitignore at commit time than at PR time?

j / k navigate · click thread line to collapse

0 comments

jacoblambda5y ago

I'm curious why people use "git add ."? I don't see the convenience over "git add -i" and quickly reading through the items to add.

Note: This is an entirely serious question and I am hoping for an answer. I promise I'm not trying to antagonise anyone. I just see so many people reaching for "add ." instead of "add -i".

closeparenOP5y ago

jacoblambda5y ago

That's fair but isn't it more work to go back and have to rebase your commits to remove something that accidentally got skipped in your .gitignore?

Basically, isn't it easier to fix a .gitignore at commit time than at PR time?

j / k navigate · click thread line to collapse