Alexander Shopov <ash@xxxxxxxxxxxxxx> writes:
> What is the difference between simple, fast forward, automatic and
> trivial merge?
"fast forward" and "trivial" (and "automatic" to some degree) are
technical terms with precise meaning. Other phrases that are
related to "merge" that are not in your list are "already
up-to-date" and "real merge".
I do not think "simple" is among these words, but I can see it used
colloquially to mean "a real merge that is easy to resolve",
e.g. "if you get conflicts that is not simple, you may have to study
what both sides did carefully before you can decide the correct
merge result".
When you are on commit X and trying to merge commit Y, various
things can happen.
* There is one case where nothing happens. You may have cloned
from another repository and the tip of the branch was at commit Y
back then---since then you built on it and you are now at commit
X, and nobody else did anything in that repository in the
meantime. You try to merge from there, and find that the tip of
the branch is still Y. Your history leading to X contains
everything the other side of the history leading to Y contains,
so there is no need to do anything.
We say that in this situation, your branch is already up-to-date.
* There is another case where no new commit is created. You may
have cloned like the above case and got commit X, and haven't
done anything since then, while others worked on the branch to
advance the tip to commit Y. You try to merge their work. Their
history leading to Y contains everything you have in your history
leading to X contains. The only thing we need is to "fast forward"
your tip of the branch from X to Y, and make the index and the
working tree to match.
We say that in this situation, your branch can be fast forwarded.
* All other cases, we need to come up with a new state that is the
result of merging X and Y, and record it as a child commit of
both X and Y, i.e. create a merge commit.
We say that this situation requires a real merge.
* When a real merge is needed, there are a few subcases.
- The two histories being merged may have changed their own set
of files, without overlap. Your commit X, since your history
diverged from the history that leads to commit Y, may have
worked only on the source file, while commit Y, since it
diverged from your history, may have worked only on the
documentation file, in a hypothetical two-file project. In
such a case, the copy of the documentation file you have at
commit X is in the state the file was in when the histories
diverged, and only the other side modified it, and we can take
the documentation file from commit Y (i.e. the other side) as
the result. Similarly, because only you changed the source
file while the other side didn't touch it, we take the source
file from commit X. We can come up with the merge result
without even inspecting the file contents.
The act of coming up with the result of the merge by pure
equality of the file contents (i.e. one side modified, the
other side left intact) is called "tree level merge", and a
merge, all of whose paths can be resolved by tree level merge,
is called "trivial merge".
- If a merge is not "trivial", we'd need to dig down to "file
level merge". The contents of a file that was touched by both
sides need to be computed.
- In a merge that requires "file level merge", you and the other
side may have modified the same file, but touched different and
non-overlapping parts. You may have updated text in section 1
of the documentation file while the other side may have fixed
typo in section 3. We use the same "three-way merge" principle
used in the "tree-level merge"; if you did not touch a part of
file that was modified by the other side, we take what the
other side did, and vice versa, to come up with the merge
result. There are other ways to mechanically come up with the
file level merge result that the user can supply (low level
merge drivers). The result of such a mechanical merge, when
successfully recorded, is often called "automatic merge".