Why does git commit after a merge by default?

Question

I'm curious about this behavior and maybe its just because I've come from using SVN and bazaar mostly. (I'm learning git to interface with the excellent github.)

It seems counter intuitive to me and as if it would be better for

git merge [branch] --no-commit

to be the default to encourage people to make sure the merge went the way they wanted it to before committing.

Answer 1

The goal set by Linus Torvalds when creating Git was to make all the merges that could be automatically solved... FAST. See his 2007 Google Tech Talk: Linus Torvalds on Git (transcript)
I.e. hundreds of merges in less than a few seconds.

So a "--no-commit" by default would pretty much defeat that purpose.

With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing.

Extract from Linus's talk (video):

The only thing that matters is how fast can you merge.
In git, you can merge... I merge 22,000 files several times a day, and I get unhappy if a merge takes more than 5 seconds, and all of those 5 seconds is just downloading all the diffs, well not the diffs but its the deltas between two trees, the merge itself takes less than half a second.
And I do not have to think about it.
[...]That's the kind of performance that actually changes how you work.