Why does git merge without conflict still cause merge?

Question

I am trying to understand why git will commit with a unique SHA1 to merge between two branches without conflicts. Does the information that conflicts were not really superfluous in the history of changes keep the information?

Answer 1

The short answer is that the commit captures the specific state of your working directory, and the merge creates a state that does not match any of the parents, so a new commit is required, and not just moving the pointer branch. However, to clarify a bit, this helps to understand what the merging of the two branches means.

The two most common git merge methods are: a) catch up with the local branch to the remote branch, and b) actually merge two separate branches together.

In the first case, you have something like this:

 A--B--C--D--E--F--G ^ ^ | +-- origin/master +-- master 

In this case, git merge origin/master simply moves the pointer to master to a new location. This is what is called a "fast forward" merge and usually does not lead to a new commit (although you can explicitly request it if you have a reason).

On the other hand, if you have something like this:

 A--B--C--D--E--F--G <-- branch1 \ J--K--L--M--N <-- branch2 

and you are on branch2 and want to merge into branch1 , just moving the branch2 pointer branch2 not make sense. If you just moved branch2 to point to G , you will lose the changes made to J through N In this case, git merge should create a new commit, where the resulting working tree will look like you took a copy of C (the merge base G and N ), which you can see by running git merge-base branch1 branch2 ), and then apply everything changes in D through G and in J through N Even if this does not lead to conflicts (two branches either changed different sets of files, or at least only different areas of files), the final working state of the directory does not correspond to either G or N , so a new commit is required. Thus, git will create a new commit with a working directory that contains the results of applying changes from both branches, and note that the commit has both G and N as parents.

Thus, in reality, this is not “storing information that there were no conflicts,” it is preserving the new unique state of your project. Of course, you can look at this post using git log , git diff , etc. And to see that either there were or were not conflicts, but this is not the reason why a new fix was made.

Answer 2

The merge commit point must include two different commit trees in the parent HEAD element.

There are three possible ways to merge:

• Create a single parent merge for each merged thing.
  This means that all the original commits from the branch you merged will still appear in your history as a separate parallel track.

• Create a fake merge merge with only one parent that contains all the folded changes.
  This leads to a simpler story (without a separate tree), but it loses all the commits of the merged branch.
  It is a bad idea.

• Create new commits for merged changes whose source branch was their parents.
  This leads to a linear history with alternating both sets of commits.
  This is what git rebase .

Answer 3

Does the information that there were no conflicts that really cost an extra mess in the history of changes?

You want a git rebase that does this. One easy way to think about using reinstallation to merge and avoid merging is to "pretend that the job happened first, not parallel."

Rebase can be dangerous to “play with” before git makes sense for you as elegant, but it solves a problem that you intuitively understand. In general, rebase is used when a raw commit history does not make sense to you. In the case of a merger, it is used when one of the parent stories, in your opinion, does not matter and should never really have happened (it “rewrites the story”). In the case of some major mergers, you really need both stories; in others, no. I omit a more complete explanation, as you can find a lot online, some better than others.