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 a Commit into a different Branch
- How to merge two seperate - yet similar - codebases into one SVN rep?
- Fixing up a commit that happened before a merge
- Merging strategy with a long development branch. How to prevent heavy conflicts in the future merge?
- Git merge one branch in all other branches
- Why would my local changes in Git be overwritten by checkout in this circumstance?
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.
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.
--no-commitperform 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.