Why does git commit after a merge by default?

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.

  • How do you merge two Git repositories?
  • Git merge - Source and destination branch name identification
  • Convert darcs repos to git with multiple branches
  • Git subtree push always fails
  • Cocoapods project.pbxproj merge conflicts
  • Merge large git commit by splitting it into small commits on master branch
  • SVN merge reintegrate missing ranges but nothing to merge
  • During a local merge, can I reset file file to merge start state (with conflicts)
  • One Solution collect form web for “Why does git commit after a merge by default?”

    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.

    Git Baby is a git and github fan, let's start git clone.