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.
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.
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.
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.
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.
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.
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.
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.
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
"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.
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.
The approach I’ve been taking lately with general AI development:
1. Define the work.
2. When working in a legacy code base provide good examples of where we want to go with the migration and the expectation of the outcome.
3. Tell it about what support tools you have, lint, build, tests, etc.
4. Select a very specific scenario to modify first and have it write tests for the scenario.
5. Manually read and tweak the tests, ensure they’re testing what you want, and they cover all you require. The tests help guardrail the actual code changes.
6. Depending upon how full the context is, I may create a new chat and then pull in the test, the defined work, and any related files and ask it to implement based upon the data provided.
This general approach has worked well for most situations so far. I’m positive it could be improved so any suggestions are welcome.
OpenTelemetry (OTel) and the OpenTelemetry Protocol (OTLP) are immensely powerful tools. The ability to emit telemetry data from any source, coupled with a receiver that can sample, filter, pipe, and potentially reshape the data to suit any need, is a game changer. This flexibility revolutionizes how we approach observability and monitoring across diverse systems.
With things like this, you realize how short life is, and sometimes how brittle it can be. I often forget that the people that built the foundation of what we use every day are still with us, and we have a short time to be able to show them appreciation before we say thank you to someone who has gone, if you know of someone that has dedicated time to something that you use, show your appreciation this week. It might be the last time that you have the opportunity to make that human contact.
As an American and working with a lot of really smart people over my career in IT, I don’t see this happening. I find most people I’ve come across suffer from imposter syndrome.
Those I know outside IT work, get paid and spend time with family. I don’t really see any superiority.
That’s just my perspective on a small part of the world. Have a great weekend all!
I wonder if this study is accidentally measuring people’s perception of their potential. I struggle a fair amount with public speaking; it’s a phobia for me, but I also know that I am capable of overcoming it if I prioritize it. So maybe I would seem to think I’m better than I am if the methodology accidentally conflates my belief about my potential with my belief about my current state?
Maybe not even with their own potential but others'. For example, nearly everyone feels that their kids are special high performers in the US, or at least hope they are. We can't all be above average. I've heard that the Japanese have a different way of viewing it - that they hope for average since that's logically what they will get, but still push for fulfilling one's full potential.
This happens due to the fact that working in IT what you see instead is that individuals they deem inferior are not hired. Racism is a very big think in both Asian and American Culture. In systems such as the University of Texas we see outcomes for Hispanics that receive degrees in technology. They just don't get jobs. The results of it are easily translated over for other ethnicities with the notable exception of African Americans which Texas surprisingly has very few African Americans and even less with a bachelors degree or higher.
It tells us a lot firstly that there is a limit to the amount of minorities that are hired every year and that it's artificially set by a group of people systemically due to varying biases, often a sense of superiority. I could list the two groups that actively participate in this but doing so is pointless.
This has helped me immensely. Nothing crazy, do 5 rounds of squats at your pace, 1 minute a part. Or sit-ups, push-ups, hollow-mans, etc. it wakes me up, and makes me want to work. I’m tired after, but that’s getting better as I get more into shape. Best of luck to all!
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.