5 ms·

> Using wildcard commands like git add *or git add . can easily capture files that should not enter a git repository No they cant, because of .gitignore

ivalm 6y ago
Because mistakes happen and adding a secret into path that is not hit by gitignore can happen. At least if you manually add you will have to consciously add the path that leaks secret. It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.
- closeparen 6y ago
  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.
  - jacoblambda 6y 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".
    - closeparen 6y 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.
      - jacoblambda 6y 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?
unethical_ban 6y ago
I think the idea is "defense in depth" - but you are correct - if you use env vars/vaults, and a proper .gitignore, this isn't an issue.

ivalm 6y ago

Because mistakes happen and adding a secret into path that is not hit by gitignore can happen. At least if you manually add you will have to consciously add the path that leaks secret. It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.

closeparen 6y ago
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.
- jacoblambda 6y 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".
  - closeparen 6y 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.
    - jacoblambda 6y 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?

unethical_ban 6y ago

I think the idea is "defense in depth" - but you are correct - if you use env vars/vaults, and a proper .gitignore, this isn't an issue.