24

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.

Will
  • 4,358
  • 2
  • 20
  • 17
  • 2
    By the way, git merge will end up with a conflict if something goes wrong. Also if for particular reason you want to see changes introduced by the merge uncommited, you may do "git reset HEAD^" right after the successful "git merge" which will step back to one commit leaving all last commit changes (which will be a merge commit) uncommited. – Ruslan Kabalin Mar 02 '11 at 10:02

1 Answers1

28

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Ah ok so basically the asumption is if you are merging its what you wanted to do and you want to get it done a quickly as possible? – Will Mar 02 '11 at 07:26
  • 2
    @Will: yes, but don't forget the other workflow: rebase your work before merging it (which would then result in a fast-forward merge: http://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804178#804178 ) – VonC Mar 02 '11 at 07:31
  • Video from the talk you reference in this answer http://www.youtube.com/watch?v=4XpnKHJAok8&feature=player_detailpage#t=3118s – Will Jun 03 '12 at 07:45