3 ms·

> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Alw

> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.

elischleifer 4y ago
I hear you. But nothing goes directly into main. The working branch is not sacrosanct you know what I mean? I'd rather clean up anything that leaks in before merging and a good .gitignore can protect against most noise.
- TrickyRick 4y ago
  Sure but it goes in the repo. Forgot to add .env to the .gitignore? You probably just committed a secret. Sure you can force push to get rid of it but if you're using Github it's still saved so it needs to be rotated now.
  - alkonaut 4y ago
    What’s “the repo” here? What I commit goes into my copy of the repo. Only what I push goes into any repo anyone else sees. Before pushing I always go through what’s in the branch and clean up/rebase etc. Sure it’s easier to accidentally push a file you shouldn’t have if you have added it locally but committing alone doesn’t necessarily mean you need to rotate a secret.
    - LocalPCGuy 4y ago
      That is a case where (as you note) you'd need to do some sort of destructive fix to eliminate the file from your local repo. Whether it's a rebase or something else, a person then needs to know "the advanced parts" that the blog post is advocating aren't really needed if "git is done correctly". Better to just not commit files/hunks accidentally in the first place - I know, it's not a perfect world, yada yada - just trying to provide the counter point to the counter point.
      - alkonaut 4y ago
        Yeah I’d say interactive rebase and soft resets is part of my “limited toolbox” for git that I wouldn’t go without. (I don’t stage hunks, don’t merge in either direction etc, so I leave some other parts of the larger toolbox alone).
- simplotek 4y ago
  > But nothing goes directly into main. That's not a reasonable argument. The problem is pushing confidential info into a repository. It matters nothing what the branch you push it is called.
  - elischleifer 4y ago
    FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.
    - simplotek 4y ago
      > FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches. Irrelevant. You're describing a failsafe. It's like claiming that you don't need to care about speed limits because a road has guardrails. The whole process is broken if it fails to address the main reason confidential info can be pushed into repositories.
denimnerd42 4y ago
nah, I always git add --all && git commit -m "issu-12 my short message" if something leaks and I need to add to gitignore I'll amend. there's definitely cases for staging more complicated edits but not in my daily work.
Forge36 4y ago
combined with the authors disdain of commit messages or documentation I can't figure out where they've chosen to document why changes are made.
- nimbus3001 4y ago
  commit messages != documentation

elischleifer 4y ago

I hear you. But nothing goes directly into main. The working branch is not sacrosanct you know what I mean? I'd rather clean up anything that leaks in before merging and a good .gitignore can protect against most noise.

TrickyRick 4y ago
Sure but it goes in the repo. Forgot to add .env to the .gitignore? You probably just committed a secret. Sure you can force push to get rid of it but if you're using Github it's still saved so it needs to be rotated now.
- alkonaut 4y ago
  What’s “the repo” here? What I commit goes into my copy of the repo. Only what I push goes into any repo anyone else sees. Before pushing I always go through what’s in the branch and clean up/rebase etc. Sure it’s easier to accidentally push a file you shouldn’t have if you have added it locally but committing alone doesn’t necessarily mean you need to rotate a secret.
  - LocalPCGuy 4y ago
    That is a case where (as you note) you'd need to do some sort of destructive fix to eliminate the file from your local repo. Whether it's a rebase or something else, a person then needs to know "the advanced parts" that the blog post is advocating aren't really needed if "git is done correctly". Better to just not commit files/hunks accidentally in the first place - I know, it's not a perfect world, yada yada - just trying to provide the counter point to the counter point.
    - alkonaut 4y ago
      Yeah I’d say interactive rebase and soft resets is part of my “limited toolbox” for git that I wouldn’t go without. (I don’t stage hunks, don’t merge in either direction etc, so I leave some other parts of the larger toolbox alone).
simplotek 4y ago
> But nothing goes directly into main. That's not a reasonable argument. The problem is pushing confidential info into a repository. It matters nothing what the branch you push it is called.
- elischleifer 4y ago
  FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.
  - simplotek 4y ago
    > FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches. Irrelevant. You're describing a failsafe. It's like claiming that you don't need to care about speed limits because a road has guardrails. The whole process is broken if it fails to address the main reason confidential info can be pushed into repositories.

denimnerd42 4y ago

nah, I always git add --all && git commit -m "issu-12 my short message" if something leaks and I need to add to gitignore I'll amend. there's definitely cases for staging more complicated edits but not in my daily work.

Forge36 4y ago

combined with the authors disdain of commit messages or documentation I can't figure out where they've chosen to document why changes are made.

nimbus3001 4y ago
commit messages != documentation