I don’t ignore by default, but only stage the items I explicitly want.

I can’t tell you how many times I’ve been pairing with someone when they just say “git add .”, I’m always confused by that choice.

I get it, but I’ve seen more problems arise from adding all than being consistently selective. To each their own.

▲ etbebl 6 hours ago | parent | next [-]

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.

▲ jameshart 5 hours ago | parent | next [-]

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 an hour ago | parent [-]

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 an hour ago \| parent [-]
		`git reset`

▲ eszed 5 hours ago | parent | prev | next [-]

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.

▲ airstrike 4 hours ago | parent | prev | next [-]

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

▲ noir_lord 6 hours ago | parent | prev [-]

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 5 hours ago \| parent [-]
		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.

▲ zelphirkalt an hour ago | parent | prev | next [-]

"git add ." ... so annoying to watch people do that, when "git add -u" is right there ... and even when you tell them why it is a bad habit, they continue doing it. I can only assume, that it is due to overly relying on GUI tools for git, that they do not understand this, or due to not having had to switch credentials everywhere due to committed secrets.

▲ dmurray 5 hours ago | parent | prev | next [-]

I try to structure my work in such a way that "git add ." is a sensible thing to do. I stashed or committed outstanding changes before starting on this feature, and I did exactly enough work for one commit since then. And the state of the project right now is what I've built and tested, so it's a good candidate to go into version control.

Changes that are needed to get the project to run right in the dev environment, but that should never be committed, are a smell: I move them to config that doesn't get committed.

Increasingly with agents I'm likely working on multiple features in parallel (I haven't adopted git worktrees but I probably should). Even then I try to lay out code so concurrent changes touch disjoint parts of the codebase, so I can do "git add Widgets/FooWidget/" and the ten files modified under there will be the right things to commit.

Maybe 30% of the time I find I have done work that belongs in multiple commits and I need to break it up. Even then I often end up doing "git add -p ." to interactively pick the parts I want to add.

▲ brunoarueira 5 hours ago | parent | prev | next [-]

In a previous company I worked for my Tech Lead usually do git add -p <file> to be extra cautious with the modifications and do a good self review after when open the pull request

▲ aequitas 5 hours ago | parent | prev [-]

Lazygit[0] is ideal for quickly selecting files or lines you want to include in your commit. There are probably countless others. And `--patch` is also not that hard.

[0] https://github.com/jesseduffield/lazygit

	▲	zelphirkalt an hour ago \| parent \| next [-]
		Magit of course also solves this very nicely.
	▲	der_gopher 3 hours ago \| parent \| prev [-]
		yes, lazygit is huge, I mentioned it in the article too