Comment by to3m

Well, you don't, so... don't do that. Same thing goes for Perforce; you can already create multiple changelists that you commit independently, so it's easy enough to create a bad commit, because it contains only some of the changes you've got locally.

What you're supposed to do in Perforce of course is to create your changelist, shelves the others, make sure your proposed changelist works independently, and commit it only when it does. Which is analogous to what you're supposed to do with git:

    - stage parts of files
    - `git stash -k'
    - check it works
    - `git stash pop'
    - commit

But let's be serious here - the true advantage of git comes when you do the pro move.

    - stage parts of files
    - commit
    - (90% of the time) it's good
    - (10% of the time) bzzt... it's bad

Now, if you were using Perforce, in the 10% case, you'd be stuffed. Somebody would come over to your desk.

    - (them) "Your commit is broken"

Now what can you do? There's no denying it... you gone done fucked up, and there's no denying it.

But with git, you have options. So let's try that again.

    - (them) "Your commit is broken"
    - (you) (confident tone of voice) "Ah no, you are using git incorrectly, you forgot to git fetchpack
      --inflate-upstream-probability-leaves --deny-downstream-packs 
      --integrate-sideway-arguments --discombobulate-flat-file-compressed-alignment-jobs
      -P -Q -J 5 -N 311 -X 0771 -R 0x134774"
    - (them) (uncertain)
    - (you) (confident gaze. Straight into their eyes. YOU = TIGER)
    - (them) (increasingly uncertain)
    - (you) (unblinking gaze. You have the upper hand. YOU = 2 TIGERS)
    - (them) (wanders off to try your technobabble)
    - (you) (fixes your commit)

There's an xkcd about this.

The advantages, I think, are clear.