Why does git merge with no conflicts still produce a merge commit? -

i'm trying understand why git produce commit unique sha1 merge between 2 branches no conflicts. storing information there no conflicts worth clutter revision history?

the short answer commit records specific state of working directory, , merge create state doesn't match either of parents, new commit required, opposed moving branch pointer. elaborate bit more, though, helps understand means merge 2 branches.

the 2 common ways git merge used a) catch local branch remote branch , b) merge 2 separate branches together.

in first case, have this:

a--b--c--d--e--f--g       ^           ^       |           +-- origin/master       +-- master 

in case, git merge origin/master moves pointer master new location. what's called "fast forward" merge, , not result in new commit (although can explicitly request 1 if have reason to).

on other hand, if have this:

a--b--c--d--e--f--g <-- branch1       \        j--k--l--m--n <-- branch2 

and on branch2 , want merge in branch1, moving branch2 pointer not make sense. if moved branch2 point g, lose changes made in j through n. in case git merge must create new commit, resulting working tree took copy of c (the merge base of g , n, can see running git merge-base branch1 branch2), , applied of changes in d through g , in j through n. if results in no conflicts (the 2 branches either modified different sets of files or @ least different areas of files), resulting working directory state not match either g or n, new commit required. git create new commit working directory contains results of applying changes both branches, , mark commit having both g , n parents.

so, it's not "storing information there no conflicts", it's storing new unique state of project. sure, can @ commit git log, git diff, etc. , see either there or weren't conflicts, that's not reason new commit made.