> I also consider `git add -A` to be horrible
> practice. Adding files manually makes you tons more
> aware
Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate.
Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
I understand what you're getting at, but unfortunately I just don't write code that way (And I'm not really sure I know tons of people that do). I always end-up making changes or realizing things halfway into working on something. That said I do understand your point, generally what I do is commit 'logical' parts of my work (Generally using `git add -i` to commit individual chunks), and then when I'm done I checkout each commit to test it compiles on its own.
The fact that `git` makes changing your history around easy make this workflow work fairly well without too much extra overhead to achieve a clean history. I don't disagree that doing it right the first time is really the best way to do it, I just don't find that it really works out that way in practice.
True, sometimes I realize I need to do something half-way when doing something else, then I do a "WIP commit", do another thing and commit that thing (sometimes in a separate branch forked off master), then perhaps reorder commits if needed, and go back to continue working on the previous thing (and amend the "WIP commit" once done)
The tricky thing is that when doing several things without committing, sometimes you can end up in a state of the repo where you can't split the work done into nice commits anymore (because you might have modified same part of code multiple times).
I usually have a paper and pen at hand, all non-current work goes there — empty circle and todo text. It was my bad habit to patch things immediately at sight. That way I sometimes missed part of context, either of main task, or secondary, depending on complexity of both.
Maybe this step-by-step working scheme was influenced by svn that cannot commit partial changes, but it seems a good practice on its own, especially in total refactoring.
> and avoid doing more than one thing in the first
> place (which would make me want to use `git add -p`)
Yep, I still _avoid_ it, but I'm often surprised by something that slips through - e.g. a typo in a comment that I just changed as I read through - but a comment somewhere totally unrelated to the present commit.
Maybe your better at avoiding it than I am, but I find it to be easily done.
I have these in my WIP branches. When I’m ready to merge, I squash out some of the smaller commits, and then merge without fast-forward. Reduces noise and keeps a clear history of groups of work, at the expense of very cheap branching and local rebasing operations.
> because you commit a state of the repo that (probably) never existed
The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
What the commenter means is that one might accidentally select some invalid or non-sensical set of partial changes (that won't compile or run) in an effort to create a logical progression between state A, "no feature", and state B, "feature is complete".
If a bug is found, the invalid state of the intermediate commits might make it harder to isolate the change that caused the bug.
That being said, I generally use "git add -p". I've gotten accustomed to trying to have clean commits. Although, sometimes the changes have enough complexity that breaking them up becomes too painful and I end up with a few messy commits. Such is life.
I think this is a good practice; it's always easy to let your attention lapse and skim over a line when you're reading the full diff. `git add -p` is nice in that it explicitly requires you to ack each change.
Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.