Updating the open source software will keep the update synchronized

Why Git merge―― is better than diff + patch

2013.2.16, Beijing

This address: http://www.jiangyouxin.net/2013/02/16/git_merge.html

It is common to develop two times based on open source software. The problem with this type of development is that when we've made a lot of changes to open source software, we're already getting farther from the upstream backbone version, when the upstream trunk is updated, how do we merge the upstream update with our own modifications? assuming the upstream backbone version is a, we developed a ' on the basis of a '; the upstream trunk is updated to B, and now we're going to update to B '.

One approach is to use the Diff tool to generate a ' and a ' difference (patch), and then apply the patch on B, expecting B '. The mathematical formula means:

B‘ = B + (A‘ - A) ???? (i, using diff & patch)

If you use Git for versioning, the above approach is feasible, but not optimal. A better approach would be to build a ' and b two branches based on a, and then execute git checkout b; git merge a '. There is a misunderstanding that the merge operation is the above formula (i), in fact, the git merge algorithm is called 3-way merge (exactly called recusive 3-way merge, when two branches have multiple co-fathers when it is more than normal 3-way The merge behaves better), expressed in the following formula:

B‘ = merge(A, A‘, B) ???? (ii, using 3-way merge)

(ii) better than (i) where?

When a patch is generated with the diff tool, every modification we make is saved to the patch together with its "positioning Information" (the line number, and the original text of the first three rows and the last three rows of the modification). When patch is applied, it looks for "location information" in the original file and then modifies the app. Well, when we apply patch (a '-a) to B, it is possible that the location information itself has been modified so that the patch fails, and the patch file needs to be modified manually.

3-way-merge can solve this problem to a great extent. for diff & Patch failures, many times the merge succeeds, while the rest creates conflicts, but modifying the conflict is more humane than manually changing patches.

The algorithm itself is not described, one example to illustrate it:

1. Version A

   mkdir testcd testgit init vi test.txt111122223333444455556666git add test.txtgit commit -m "init"

2. Version a ', located in branch B1

   git checkout -b b1vi test.txt  # 插入一行abcdefg，尾部增加一行bottom111122223333abcdefg444455556666bottomgit add test.txtgit commit -m "modified on b1"

3. Version b, located in branch B2

   git checkout master -b b2vi test.txt  # 顶部增加一行add top line，“2222”做了修改，尾部增加一行bottomadd top line1111222222223333444455556666bottomgit add test.txtgit commit -m "modified on b2"

4. Version B ', merge successfully with Git merge

   git checkout -b testmergegit merge b1cat test.txt # 两条分支的修改成功合并，注意尾部的bottom也只增加了一行             # 如果用 patch & diff 方法，             #   因为patch的两个定位信息（行号、上下文）都遭到了破坏             #   是一定不会成功的add top line1111222222223333abcdefg444455556666bottom

From the above example, you can also see the 3-way merge algorithm basically:

• Two branches if one branch changes somewhere and the other branch is unmodified, the modification is preserved

• Two branches if all changes are made to a certain place, and the content of the modification is the same, the modification is preserved (not done two times)

The 3-way merge generates a conflict in the following scenario:

• Two branches if all changes are made to one place and the content is different, a conflict occurs

As for what is called "somewhere", it is based on the three versions of the LCS (the longest common subsequence) identified, will not repeat.

Reference: http://www.jiangyouxin.net/2013/02/16/git_merge.html

Updating the open source software will keep the update synchronized