[Hero CDMA Android Development] s0be:
This all assumes you have decent C experience, and understand that this is going to be about as far from OOP as anything you've ever experienced. Your mad visual basic skillz are worth nothing here.

Wish I had a good answer for you here bubs... It's been a long time since I first started looking at kernel devving (my first work was on version 2.5.57) and it was always small module work. It takes a while to get to the point you can work on even a whole subsystem at once, where you have to make changes to multiple files and have them interact correctly.

Some useful things:

Git Tricks:

Lets say you have a git tree you're working in (god knows you should).

Git remote add (alias) (git server address)

Creates a way you can directly reference someone else's tree. From there you might do:

git pull (alias) (branch)

To merge things that have changed in that branch since your fork from it.

or

git merge (alias) (branch)

to merge your changes onto their changes since the fork.

If there are conflicts, git status will list files that need editing/fixing. When you open the file, do a search for <<<< to find the conflict. The code between <<<< and ==== is what is in the current working tree. The code between ==== and >>>> is what is in the tree you're merging. It's up to you to determine what parts of each needs saved (about half the time you just drop what was in the working tree, the other half, what's coming from the new tree. It's not very common in my experience that you have to use part of both).

When any of these becomes too daunting, and you want to abort, do:

git reset HEAD^

git reset --hard

To reset your tree to the last push/pull to it's base git server.

Rather than merge, rebase, or pull, I usually cherry pick. What I do is go on github, browse the person's tree, and find a commit I think will work well for me. I then add the github as a remote, then do:

git cherry-pick (committish)

If there are merge conflicts, resolve them like before. The nice thing about this approach is you can test single commits from other trees to see if they work for you. This is how I merge stuff from riemer, pershoot, cm-kernel, decadence, and damn near any other useful git tree I can find. Here's my current list of remotes:

cmupstream	https://github.com/CyanogenMod/cm-kernel.git (fetch)
dec	https://github.com/Decad3nce/cm-kernel.git (fetch)
feeyo	https://github.com/Feeyo/cm-kernel.git (fetch)
g1	https://github.com/pershoot/kernel-2635.git (fetch)
htc-kernel-msm7227	git://github.com/CyanogenMod/htc-kernel-msm7227.git (fetch)
jmup	git://github.com/JasonMaloney/cm-kernel.git (fetch)
origin	git@github.com:s0be/cm-kernel.git (fetch)
pup38	https://github.com/pershoot/kernel-2638.git (fetch)
rupstream	https://github.com/riemervdzee/cm-kernel.git (fetch)

I watch all of those for useful stuff.

Now, when you get done with a bunch of merging, get testing, and find a bug, you need to do a bisection. (I'm actually doing this right now)

You do:

git bisect start

git bisect bad (this flags the current commit as being bad)

git bisect good <committish> (this marks a time in the past where it worked)

You'll then have to build a kernel, boot and test. Once you've tested if the problem is there, you do git bisect good if it worked, and git bisect bad if it didn't. If there's some other bug biting you on a particular commit, and you're unable to test it, you'd do: git bisect skip. Depending on where these problem commits fall in a bisection, you could have to do manual testing on these reverts you skipped, by checking out that particular commit, then cherry-picking the fixes onto it. This can get kinda ugly though

That's a good introduction. I've bisected the commit that broke camera, so I'm reverting and testing now. I'll try to write up a quick synopsis of the different drivers and what they do for the heroc later.