Here is the next step on how to look for merge conflicts between two branches in your nook color linux branches, any merge conflicts can lead to bugs in your kernels. We will have to take a look on how to use Kdiff3 in your Git extensions by reading this online guide here. This is where I am at right now, trying to patch merge conflicts. What I did is load a line of code in Git extensions and select the Diff tab below, then I right clicked on that code in the diff tab and selected open diff. There you will see the two different branches corresponded in your kdiff 3 like we went over in the upper box above. Remember our highlights to the kdiff 3 to your upper box in git extensions? We select the "device.mk" for our example file in our diff. SEE uploaded picture examples below.
Next we go up in the merge tab option in kdiff 3 and open it. I am using the "in-line kernel building" that is highlighted in blue as our example from Git extensions. WE hit the option in that open tab now to " merge current files."
Here is the Kdiff manual we will have to read to get up to speed on using that tool.
http://docs.kde.org/...iff3/kdiff3.pdf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the first upload example below we will see the merge conflict where I circled the problem in black. We will have to fix this problem and submit our patch. BE CAREFUL here when you make changes back to the main code in the master branch or your patch will not be submitted to the github. Typing and uppercase and space alignment are important here. Do you see the discrepancy? One of the lines of code has the word "KERNEL" there and the other line of code has the line with " BOOTLOADER" . WE will change it back to the correct word from the main branch and submit our patch for it on the github for review. The second line could be correct too by the other developer, the patch will merge into the other branches for submission on the github with the correct change from what I understand on this.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After we go in and solve these merge conflicts; I had two merge conflicts for the "device.mk" example; you will go up in your tab in kdiff3 and select Choose A for all unsolved conflicts, ( A is the master branch for this example,) and watch the bottom box clear out the merge conflict lines in red. THIS keeps you from having to go in and typing by hand for the code. You can now save your work to a folder somewhere on your computer, then see your results you made in a new file! Then you can right click on the new file with the saved merged resolved conflicts. Stage it with git Extensions and make commits on your work. MAKE sure you leave a description on what you did in your commits so other developers know what you did. For my example I left the commit, " "solved merge conflicts in "device.mk""" You are ready to push your first patch onto the github for review. You will be prompted by KDIFF3 if you have any merge conflicts you did not solve before you quit.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before you push make sure you pull from your URL on the github first so the other developers do not have to resolve the same conflicts you just solved, making it easier on yourself and other developers. That means pulling from your own master branch, or origin. Someone could have solved the same issue you are working on already while you were away from the computer. Just like in real life you need to water your own tree before you add your resolve, the analogy for this is like grafting a leaf to that limb you have on the collective tree that is online. Think in terms of taking care of your own Bonsai tree when you work on the github. On git extentions I just select the last file that I saved from my KDIFF3 I worked on and left click on it , then pull to update. You will see a progress bar. UGGGH the github can be slow to download those updates too.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also if you get files that are being staged from wherever you saved your diff to you can right-click on those files and choose .gitignore on your git extensions so you do not have to keep staging files you do not need. It will save these staged ignores somewhere on your computer in a notepad extension for later use.
~~~~~~~~~~~~~~~~~~~
Remember you can select actions in your file with "git extensions" when you right click on it for creating branches if you have to, for cloning branches, and other options available to you if you come across errors pushing your changes to your ICS nook color master branch. You can apply patches to your saved diff and other options too.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I just inputed one error I got into Google search bar for this one error I had trying to push my resolved file onto the github. Said my branch was too bushy or along that line right at the tip of it, because I pushed that file more than once. Just like on a real IRL tree you can prune your branches with git if your branch gets too bushy, it would stop growth on that branch too just like on a real tree. The main trunk of that tree is <fattires> for the ICS nook color branch. You are just putting in a master branch onto this tree from your github page onto the cloned repositories for the ICS nook color branch. JUST like grafting in a limb on your own COLLECTIVE bonsai tree. Its also SO like the movie TRON.
Your leaf, the resolves you made, help feed this imaginary tree through its photosynthesis, helps it grow and makes it more healthy. That MEANS a more , less buggy ICS on your nook color for you! Here is a link for that one error I got trying to push.
http://stackoverflow...erence-from-git
2
I want lots and lots of comments. My handle will be the same as it is on here on the forums, <meteorrock> ok? ok. Feel free to PM me or anything too. I am using the newest theme there the XDA 2013 theme which makes me want to use it now. 
Those guys over at #nook color were something else.
These kernel hacks are wicked hard. I got code all over the place here on my battlestation. I want to find it and kill it for good. You could help too if you even pulled anything over on the github. Where are you? I am getting closer now. Starting to learn how to merge my branches. Email me back. I want to be the one to find that bug and submit a patch first.
