Different merges from translation perspective

Different merges from translation perspective

[Alexander Shopov]

Hi all,
What is the difference between simple, fast forward, automatic and
trivial merge?
I am updating the translation and the only thing I am sure about is
that these four are not octopus merges,
Fast forward is when current state is ancestor of tip, automatic merge
is when the merge algorithm is decided by git rather than developer.
What about simple (git-merge-octopus.sh) and trivial
(builtin/merge.c)?
Kind regards:
al_shopov

Re: Different merges from translation perspective

[Jacob Keller]

On Sun, Jan 15, 2017 at 8:41 PM, Alexander Shopov <ash@kambanaria.org> wrote:
> Hi all,
> What is the difference between simple, fast forward, automatic and
> trivial merge?
> I am updating the translation and the only thing I am sure about is
> that these four are not octopus merges,
> Fast forward is when current state is ancestor of tip, automatic merge
> is when the merge algorithm is decided by git rather than developer.
> What about simple (git-merge-octopus.sh) and trivial
> (builtin/merge.c)?
> Kind regards:
> al_shopov

Hi,

I'm not sure exactly what the documentation says regarding all of these things.

I know for sure that a fast-forward merge isn't "really" a merge in
the sense that no merge-commit is generated. Instead, the current
branch is simply fast-forwarded to the new result (since it's a direct
ancestor of the new tip.

I don't really have any answers for the others.

Thanks,
Jake

Re: Different merges from translation perspective

[Junio C Hamano]

Alexander Shopov <ash@kambanaria.org> 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".