{"thread":{"id":"44890","subject":"Different merges from translation perspective","startedAt":"2017-01-16T04:50:25Z","lastAt":"2017-01-16T07:44:46Z","messageCount":3,"participants":["Alexander Shopov","Jacob Keller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309469","messageId":"CAP6f5MkOoDUqHCvLNQ+xJGWTbrdecet9W_JK5y7JeAnBpGeAaw@mail.gmail.com","threadId":"44890","inReplyTo":null,"subject":"Different merges from translation perspective","fromName":"Alexander Shopov","fromEmail":"ash@kambanaria.org","sentAt":"2017-01-16T04:41:57Z","receivedAt":"2017-01-16T04:50:25Z","isPatch":false,"sender":{"key":"ash@kambanaria.org","avatar":"https://avatars.githubusercontent.com/u/449359?v=4"},"body":"Hi all,\nWhat is the difference between simple, fast forward, automatic and\ntrivial merge?\nI am updating the translation and the only thing I am sure about is\nthat these four are not octopus merges,\nFast forward is when current state is ancestor of tip, automatic merge\nis when the merge algorithm is decided by git rather than developer.\nWhat about simple (git-merge-octopus.sh) and trivial\n(builtin/merge.c)?\nKind regards:\nal_shopov\n"},{"id":"309470","messageId":"CA+P7+xqcU96siyNrjNF8Tze4Nbf3k-oJBZ2g8xeYLU92AX-0rQ@mail.gmail.com","threadId":"44890","inReplyTo":"CAP6f5MkOoDUqHCvLNQ+xJGWTbrdecet9W_JK5y7JeAnBpGeAaw@mail.gmail.com","subject":"Re: Different merges from translation perspective","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-16T06:00:13Z","receivedAt":"2017-01-16T06:00:41Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Jan 15, 2017 at 8:41 PM, Alexander Shopov wrote:\n> Hi all,\n> What is the difference between simple, fast forward, automatic and\n> trivial merge?\n> I am updating the translation and the only thing I am sure about is\n> that these four are not octopus merges,\n> Fast forward is when current state is ancestor of tip, automatic merge\n> is when the merge algorithm is decided by git rather than developer.\n> What about simple (git-merge-octopus.sh) and trivial\n> (builtin/merge.c)?\n> Kind regards:\n> al_shopov\n\nHi,\n\nI'm not sure exactly what the documentation says regarding all of these things.\n\nI know for sure that a fast-forward merge isn't \"really\" a merge in\nthe sense that no merge-commit is generated. Instead, the current\nbranch is simply fast-forwarded to the new result (since it's a direct\nancestor of the new tip.\n\nI don't really have any answers for the others.\n\nThanks,\nJake\n"},{"id":"309472","messageId":"xmqq37gjbg9o.fsf@gitster.mtv.corp.google.com","threadId":"44890","inReplyTo":"CAP6f5MkOoDUqHCvLNQ+xJGWTbrdecet9W_JK5y7JeAnBpGeAaw@mail.gmail.com","subject":"Re: Different merges from translation perspective","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-16T07:44:35Z","receivedAt":"2017-01-16T07:44:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexander Shopov writes:\n\n> What is the difference between simple, fast forward, automatic and\n> trivial merge?\n\n\"fast forward\" and \"trivial\" (and \"automatic\" to some degree) are\ntechnical terms with precise meaning. Other phrases that are\nrelated to \"merge\" that are not in your list are \"already\nup-to-date\" and \"real merge\".\n\nI do not think \"simple\" is among these words, but I can see it used\ncolloquially to mean \"a real merge that is easy to resolve\",\ne.g. \"if you get conflicts that is not simple, you may have to study\nwhat both sides did carefully before you can decide the correct\nmerge result\".\n\nWhen you are on commit X and trying to merge commit Y, various\nthings can happen. \n\n * There is one case where nothing happens. You may have cloned\n from another repository and the tip of the branch was at commit Y\n back then---since then you built on it and you are now at commit\n X, and nobody else did anything in that repository in the\n meantime. You try to merge from there, and find that the tip of\n the branch is still Y. Your history leading to X contains\n everything the other side of the history leading to Y contains,\n so there is no need to do anything.\n\n We say that in this situation, your branch is already up-to-date.\n\n\n * There is another case where no new commit is created. You may\n have cloned like the above case and got commit X, and haven't\n done anything since then, while others worked on the branch to\n advance the tip to commit Y. You try to merge their work. Their\n history leading to Y contains everything you have in your history\n leading to X contains. The only thing we need is to \"fast forward\"\n your tip of the branch from X to Y, and make the index and the\n working tree to match.\n\n We say that in this situation, your branch can be fast forwarded.\n\n\n * All other cases, we need to come up with a new state that is the\n result of merging X and Y, and record it as a child commit of\n both X and Y, i.e. create a merge commit. \n\n We say that this situation requires a real merge.\n\n * When a real merge is needed, there are a few subcases.\n\n - The two histories being merged may have changed their own set\n of files, without overlap. Your commit X, since your history\n diverged from the history that leads to commit Y, may have\n worked only on the source file, while commit Y, since it\n diverged from your history, may have worked only on the\n documentation file, in a hypothetical two-file project. In\n such a case, the copy of the documentation file you have at\n commit X is in the state the file was in when the histories\n diverged, and only the other side modified it, and we can take\n the documentation file from commit Y (i.e. the other side) as\n the result. Similarly, because only you changed the source\n file while the other side didn't touch it, we take the source\n file from commit X. We can come up with the merge result\n without even inspecting the file contents.\n\n The act of coming up with the result of the merge by pure\n equality of the file contents (i.e. one side modified, the\n other side left intact) is called \"tree level merge\", and a\n merge, all of whose paths can be resolved by tree level merge,\n is called \"trivial merge\".\n\n - If a merge is not \"trivial\", we'd need to dig down to \"file\n level merge\". The contents of a file that was touched by both\n sides need to be computed. \n\n - In a merge that requires \"file level merge\", you and the other\n side may have modified the same file, but touched different and\n non-overlapping parts. You may have updated text in section 1\n of the documentation file while the other side may have fixed\n typo in section 3. We use the same \"three-way merge\" principle\n used in the \"tree-level merge\"; if you did not touch a part of\n file that was modified by the other side, we take what the\n other side did, and vice versa, to come up with the merge\n result. There are other ways to mechanically come up with the\n file level merge result that the user can supply (low level\n merge drivers). The result of such a mechanical merge, when\n successfully recorded, is often called \"automatic merge\".\n"}]}