The handling of Workstart-patch conflict

The main task today is to solve patch conflict issues in the platform upgrade process.
--The main work flow
1. Download the project source with patch conflict
2. Execute the git pull command under the corresponding source code module to determine the latest source code
3. Perform patch2 under the main directory, and you can see the patches
4.patch2+ serial number, you can see the conflict in this patch
5. After this patch2 instruction, will automatically generate a file confilct_patch_list, into the inside, you will see all the existing patch conflicts, copy this file to do a retention control
6. From your own Gerrit platform, find someone else's patch, then open the inside of the Cherry-pick, put the following repo fetch .... Just copy it, okay?
7. When executing PATCH2 again, a confilct_patch_list file will be generated again, then compare two files to find the newly added conflicting patch file
8. In principle, you can find the conflict by comparing the latest source code with the patch, but the quicker way is that you use
git apply Patch.name, when there is a conflict in the place, will give a specific line of code hints, you open the code and patch to control the line

--After the conflict source is found, the method is modified as follows:
In fact, the first thing you need is to understand the role of this patch and modify it according to the function.
Of course, if you are completely not understand the situation, but also can be modified, this is, see your patch and the latest source of the difference
1. First locate the source where the patch conflict exists
2. Make a patch backup that needs to be modified, and then delete the conflicting patch
3. Post the deleted patch into the source code to see if there are any conflicts with other patches (git apply patchname)
4. In the source code to manually input the patch into the source code (this is actually the source of the content you want to modify)
5. You can use Git diff right now. >filename (Of course, you can still use git add for insurance purposes.) Then you use git diff--cached>filename)
6. This time you have successfully generated a new patch filename, and then you have to cover the vener/vanzo_custom/patch_projects/packages/apps/dialer below the patch out.
--How to modify future patch submissions
At this point you can directly use the command git push vanzo head:refs/for/(version number) on it.



--a summary of several conceptual understandings

1.patch
Today to patch is a little understanding, has been feeling very hazy, today is to mention thrillingly tube top. Originally, Patch is actually a kind of code substitution, we want the code to implement what kind of modification, but we do not want to change the generality of the code, this time can be implemented by patch. It is plainly, I put a code quickly modified later, whenever the program is compiled, the compiler will automatically replace the patch. Today, when we were in the dapatch, we felt like we were actually lazy. Because we borrowed git diff from git management. And every time we modify a different patch, we will take one step: cc This action is to eliminate the git commit after the cache or not submit the content of the surface, its role is to let us change the source code back to the original appearance. In this case, as to how the compiler recognizes patches, mainly by naming rules, our patch names, such as MODIFY_SELETETEXT_SIZE.PATCHSET.MT71_C39_DUTAR_TAIJI_GSM, Modify_ Seletetext_size is a description of this patch feature, and the following mt71_c39_dutar_taiji_gsm is the corresponding project name

--Pay attention.
1. When we execute PATCH2, this command is executed under the root directory of the project and executed under other modules, without effect, for git apply is under the Target module folder. Git fetch is under the target module under Ventor.

2. If we compare the number of patches two times, the second time if there is less conflict than the first one, we are not allowed to change this time, of course, this situation is very small. More to show that after we have modified the source code, there has been a new patch conflict

3. When we use PATCH2, we may find some modules are not, we can use the following method to add
Vim/git vanzo_team/xulei/patch2.py Add an option to the All_module_aw

The handling of Workstart-patch conflict