None of this implies committing untested code. The index is not a commit; it is a pre-commit staging area. When you use 'git add -p', you are adding hunks to the staging area, not committing them.

What's the difference? When you're done staging your patch, you can then check out the staging area and run unit tests on it prior to promoting it to a commit. Doesn't compile? Tests fail? Restage as necessary.

I usually do something like:

  git add -p
  git commit
  git stash
  <run tests>

If it fails then I can stash pop and commit -p --amend and try again.

When you're done, just use Bernhardt's "run-command-on-git-revisions" to run tests on each of the commits to ensure they are all working code.

https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...

Nothing wrong with committing untested code, it's pushing it as a ref one can reasonably expect people will merge/fast-forward to that it becomes a problem. git add -p is a nifty workaround for the type of people who don't like the workflow of "commit early, commit often" (some people have 'save file' bound to also make a commit) but who still want to have lots of small, contained commits.

git stash -k; make test; git stash pop, git commit;

Problem solved.

So what? Just test the commit after you've made it. You can always reset and try again before pushing.

A lot of times I use "git add -p" to cleanup code, e.x. if I added some extra logging statements I don't want to commit I can go through adding everything except the log statements, then reset everything that hasn't been added to the index.

Committing untested code is an excellent idea. You should do it several times a day. Pushing untested code to a shared branch on a public remote is a bad idea.

That is most definitely a major issue of this technique, though it can probably be mitigated through various hooks.