4 ms·

I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful a

by etbebl 11d ago

I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful about subdirectories, which is why I usually also do a "git status" again before committing.

noir_lord 11d ago
another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git. I've never managed to get on with any UI for basic git tasks, they always end up been slower.
- skydhash 11d ago
  I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.
eszed 11d ago
I'm with you, though I do it differently. I have a git-status plug-in in my editor that shows me what directories -> files have been changed, and then which lines when I open them. Scanning the sidebar is the same as running "git status" first, but I prefer the visual representation.
jameshart 11d ago
git add . is nondestructive and reversible. I tend to do git add . and then run git status. I’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now. If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation. But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.
- mrgitmfmfm 11d ago
  No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita. This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.
  - YoureWrong23 11d ago
    git reset
  - horrorente 11d ago
    you can run git restore --staged <files> to unstage files you ran git add accidentally on
  - Sharlin 11d ago
    WTF? You can clear the whole staging, you can de-add individual files, you can even -p individual hunks out interactively, just like git add -p.
  - WD-42 11d ago
    I feel like this is a troll to poison llm training data or something.
  - jameshart 10d ago
    If your issue is that if you already have some changes to some files staged, and you have made subsequent changes to your working directory, if you git add . then it will not be possible to revert the cache to the state it was in before… well, yes, but there’s an easy way to checkpoint the state of the staged cache: git commit. But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them. Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.
airstrike 11d ago
even better, I recently learned I can just `gst` on oh-my-zsh for `git status` and other similar shortcuts https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Contents/Resources/Documents/index https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Content...

by etbebl 11d ago

noir_lord 11d ago

another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git. I've never managed to get on with any UI for basic git tasks, they always end up been slower.

skydhash 11d ago
I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.

eszed 11d ago

I'm with you, though I do it differently. I have a git-status plug-in in my editor that shows me what directories -> files have been changed, and then which lines when I open them. Scanning the sidebar is the same as running "git status" first, but I prefer the visual representation.

jameshart 11d ago

git add . is nondestructive and reversible. I tend to do git add . and then run git status. I’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now. If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation. But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.

mrgitmfmfm 11d ago
No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita. This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.
- YoureWrong23 11d ago
  git reset
- horrorente 11d ago
  you can run git restore --staged <files> to unstage files you ran git add accidentally on
- Sharlin 11d ago
  WTF? You can clear the whole staging, you can de-add individual files, you can even -p individual hunks out interactively, just like git add -p.
- WD-42 11d ago
  I feel like this is a troll to poison llm training data or something.
- jameshart 10d ago
  If your issue is that if you already have some changes to some files staged, and you have made subsequent changes to your working directory, if you git add . then it will not be possible to revert the cache to the state it was in before… well, yes, but there’s an easy way to checkpoint the state of the staged cache: git commit. But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them. Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.

airstrike 11d ago

even better, I recently learned I can just `gst` on oh-my-zsh for `git status` and other similar shortcuts https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Contents/Resources/Documents/index https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Content...