I've had several people asking me to "make a tutorial" on this. You're in for a bad time if you can't be semi-intuitive about it. I literally figured all of this out myself. Should this save you some time? Yes. But it won't make you a "1337 coding hax0r" (which I'm not, either. I don't even know java). Every day you'll learn something new. "Ah! So that prevents it from turning on by default!" "Oh, that makes the actual checkbox appear!" Expect some hickups. Expect to do some reading. Expect staring at your PC for an hour and realizing you're lost. These things happen.
So you've been playing around in Gerrit; cherry-picking experimental features, using a mergetool to resolve conflicts, learning to fix your own mistakes...
What's the next step? Where should you go from here to start helping the community and developers along?
How about moving features or fixes forward from old versions of AOKP?
Now, I'm going to be showing you an extremely simple example. Your challenges WILL be harder.
But that's part of the "fun" (or so they keep telling me).
Getting Started:
Familiarize yourself with the basics of Gerrit through Roman's Tutorial.
You're going to want to set up and account on Gerrit, and follow the commands listed to get your Keys set up and authenticated with Gerrit.
Now, find yourself a commit (and it's dependencies) you'd like to port upwards. The easiest way to do this is using Gerrit's search function.
To express myself easily with this tutorial, I'll be using examples. Please don't upload these exact commits 200 times <_<.
I'll be using THIS and THIS.
You'll notice that these commit's have titles that end in (?/2).
This is an indication that they require pieces in more than one location to work.
Any feature in RomControl or Settings will have two commits (usually within /frameworks/base/).
Make sure you find all of the required pieces before moving forward.
You're going to want to "cd" to the projects now and start a repo.
This is explained in Roman's Tutorial.
For example:
The repo name does NOT matter. Name it whatever is going to be easy to remember.
Now, we want to look at what this commit changed.
Under the latest patchset to the commit you'll see a list of files. You're going to want to click each one and open their respective files on your PC. For example, I see "security_settings_chooser.xml" is the only file listed for this commit. So I'll click on it in Gerrit, and see if the file exists on my PC.
It does! So that's a good thing. It means we're probably going to be able to move this forward without finding a new file location and how to merge it into the file.
Now we want to look and see if the changes are going to merge into the file without giving us a hassle.
Will it give us a hassle?
FULL SIZE IMAGE
Nah, that looks about like the file I'm looking at so the changes should be easy.
Now, the green blocks in Gerrit means something completely new was added.
So we have a block of code here that we need to copy into the file.
Oh god! What have we done...it looks like I just gave this file a disease...
Wait a second. Before you go and put this disgusting creature out of it's misery, let's try and fix it.
See how the first "<ListPreference" is indented?
And all of those nasty little red numbers?
Delete all of that and make sure your change lines up where it should (in comparison to Gerrit and the other blocks in this file).
You'll also want to make a run-through with your cursor. I use the arrow keys on my keyboard and roll my cursor all over the lines to make sure it doesn't make any huge jumps (indicating an indent) or any extra spaces after a line is finished. You don't want spaces after a line at all.
And you don't want indents at all.
So I wrapped up my changes...now I'll save the file.
Now in the Terminal:
You'll see a list of untracked files. These are backup files of the files you just changed and saved.
This is the only file I'm seeing.
We want to remove it!
How? Add "rm ." before the location that the Terminal spat out.
And the file disappears.
Now we're ready to add these files and prepare them for upload.
Then type:
Now. We're going to want to be careful here.
The simplest way to be polite and give proper credit is to copy the commit message from the old commit.
Let's look at this commit.
I'm going to cut off the "Signed-off-by" and "Change-Id" lines.
What if we screwed something up? We don't want the owner of this commit to be responsible!
And the Change-Id? This is a different commit. Not a patch of the old one.
Now you want to paste your commit message into the Terminal and hit ctrl+x afterwards.
Save Modified Buffer? (type "y" to answer yes).
Messsage to write? (just hit enter).
Yay! We're ready to upload!
Did you author this commit?
No, you didn't.
So we're going to make the original author the author of this commit as well.
See the author line there?
Copy it from your commit.
Now in your Terminal, type:
For me, I'll use:
Yay! We're ready to upload!
No. Make a build and see if it works.
Did it?
Sure. Why not.
Remember. We have another commit to add!
Ok so what were the changes in the /frameworks/base/ package?
FULL SIZE IMAGE
Red lines means something was changed. So we can see here that this:
Was removed.
Save and reupload...and you're ready to rock!
-Don't make the team hate me for writing this by uploading things that don't work or have author, whitespace, or other annoying errors.
-There are other ways (cherry-picking and rebasing which I find confusing) to do this.
-Use Roman's Tutorial for uploading new patchsets to your commit (if you make little errors like missing a tab/space/etc you can fix it here).
-Learning to read the code a little bit? Cool. Maybe you should move on to repo syncing the old 4.1 code and checking to see of the commit had fixes uploaded to it after the commit you're moving up. You can then easily copy from the old code into the new and include all fixes!
-You smell like roses <3
So you've been playing around in Gerrit; cherry-picking experimental features, using a mergetool to resolve conflicts, learning to fix your own mistakes...
What's the next step? Where should you go from here to start helping the community and developers along?
How about moving features or fixes forward from old versions of AOKP?
Now, I'm going to be showing you an extremely simple example. Your challenges WILL be harder.
But that's part of the "fun" (or so they keep telling me).
Getting Started:
Familiarize yourself with the basics of Gerrit through Roman's Tutorial.
You're going to want to set up and account on Gerrit, and follow the commands listed to get your Keys set up and authenticated with Gerrit.
Now, find yourself a commit (and it's dependencies) you'd like to port upwards. The easiest way to do this is using Gerrit's search function.
Code:
message:SEARCHTERM
To express myself easily with this tutorial, I'll be using examples. Please don't upload these exact commits 200 times <_<.
I'll be using THIS and THIS.
You'll notice that these commit's have titles that end in (?/2).
This is an indication that they require pieces in more than one location to work.
Any feature in RomControl or Settings will have two commits (usually within /frameworks/base/).
Make sure you find all of the required pieces before moving forward.
You're going to want to "cd" to the projects now and start a repo.
This is explained in Roman's Tutorial.
For example:
Code:
cd ~/aokp_jb/frameworks/base/
repo start portlocktime .
Now, we want to look at what this commit changed.

Under the latest patchset to the commit you'll see a list of files. You're going to want to click each one and open their respective files on your PC. For example, I see "security_settings_chooser.xml" is the only file listed for this commit. So I'll click on it in Gerrit, and see if the file exists on my PC.

It does! So that's a good thing. It means we're probably going to be able to move this forward without finding a new file location and how to merge it into the file.
Now we want to look and see if the changes are going to merge into the file without giving us a hassle.
Will it give us a hassle?

FULL SIZE IMAGE
Nah, that looks about like the file I'm looking at so the changes should be easy.
Now, the green blocks in Gerrit means something completely new was added.
So we have a block of code here that we need to copy into the file.

Oh god! What have we done...it looks like I just gave this file a disease...
Wait a second. Before you go and put this disgusting creature out of it's misery, let's try and fix it.
See how the first "<ListPreference" is indented?
And all of those nasty little red numbers?
Delete all of that and make sure your change lines up where it should (in comparison to Gerrit and the other blocks in this file).
You'll also want to make a run-through with your cursor. I use the arrow keys on my keyboard and roll my cursor all over the lines to make sure it doesn't make any huge jumps (indicating an indent) or any extra spaces after a line is finished. You don't want spaces after a line at all.
And you don't want indents at all.
So I wrapped up my changes...now I'll save the file.
Now in the Terminal:
Code:
git status
Code:
/res/xml/security_settings_chooser.xml~
We want to remove it!
How? Add "rm ." before the location that the Terminal spat out.
Code:
rm ./res/xml/security_settings_chooser.xml~
Now we're ready to add these files and prepare them for upload.
Code:
git add -A
Code:
git commit -a
The simplest way to be polite and give proper credit is to copy the commit message from the old commit.
Let's look at this commit.
Code:
Lockscreen: Add timeout and instant lock option to slide lock (1/2)
This adds AOSP's new timeout and instant lock options to the
slide (aka chooser) style lockscreen.
To Do: Add the vibrate option as well.
Change-Id: I5d48282e484b325a3c15f2966077222dc753026f
Signed-off-by: KhasMek <Boushh@gmail.com>
What if we screwed something up? We don't want the owner of this commit to be responsible!
And the Change-Id? This is a different commit. Not a patch of the old one.
Code:
Lockscreen: Add timeout and instant lock option to slide lock (1/2)
This adds AOSP's new timeout and instant lock options to the
slide (aka chooser) style lockscreen.
To Do: Add the vibrate option as well.
Save Modified Buffer? (type "y" to answer yes).
Messsage to write? (just hit enter).
Yay! We're ready to upload!

Did you author this commit?
No, you didn't.
So we're going to make the original author the author of this commit as well.

See the author line there?
Copy it from your commit.
Now in your Terminal, type:
Code:
git commit --amend --author="USERNAME <email@whateveah.com>"
For me, I'll use:
Code:
git commit --amend --author="KhasMek <Boushh@gmail.com>"
Yay! We're ready to upload!
No. Make a build and see if it works.
Did it?
Sure. Why not.
Code:
repo upload .
Remember. We have another commit to add!
Ok so what were the changes in the /frameworks/base/ package?

Red lines means something was changed. So we can see here that this:
Code:
|| !mLockPatternUtils.isSecure()
Save and reupload...and you're ready to rock!
- Me: That's it.
- You: You son of a *****.
- Me: What?!
- You: You just uploaded the easiest commit ever. I could have used that to start off!
- Me: If you're going to learn anything, you need to work at it. JK this would have been perfect. My bad.
-Don't make the team hate me for writing this by uploading things that don't work or have author, whitespace, or other annoying errors.
-There are other ways (cherry-picking and rebasing which I find confusing) to do this.
-Use Roman's Tutorial for uploading new patchsets to your commit (if you make little errors like missing a tab/space/etc you can fix it here).
-Learning to read the code a little bit? Cool. Maybe you should move on to repo syncing the old 4.1 code and checking to see of the commit had fixes uploaded to it after the commit you're moving up. You can then easily copy from the old code into the new and include all fixes!
-You smell like roses <3