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.

If I do such minor corrections, I usually commit them immediately (via `git add -p` or better `git commit -p`), so they are out of my way.

  git status
  ...

Yep, those are the things I changed

  git add -A
  git status

Yep...

  git commit

...editing in VI... :wq

Mischief managed.

Yep that's the way to do it. Assume that you want to add all files (which is usually the case) and then just double check before. This is my practice.

Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?

That's a scenario for branch-then-cherrypick :)

Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.

Or just `git rebase -i origin/master` and delete the unnecessary commits without additional branching.

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.

I recommend using `git commit -p`, which is a shorthand for `git add -p` followed by `git commit`.

Then, `git show` before you do `git push`.