[Galaxy S I9000 General] kasper_h:
http://review.cyanogenmod.com/#change,14261

http://review.cyanogenmod.com/#change,14215

This are two nice commits of last week. And specifically for me, the improvements of the Dutch translations are also nice.

But I will keep on building & using CM7 at least this month: I have to travel a lot and will be without pc. So I don't want to risk playing around with CM9 (I've read too often problems requiring Odin in the CM9-alpha thread), even though I know that for most people CM9 works fine....

---------- Post added at 09:40 AM ---------- Previous post was at 09:21 AM ----------

The guide you quoted is a great writeup of branching and such. I also wrote in a different thread my own way of dealing with branches/cherry-picks:

To cherry-pick I do:

>cd ~/android system

>repo sync (to be up-to-date)

>cd /cherrypicklocation (e.g. /frameworks/base)

>git branch --track localtesting github/gingerbread (by tracking remote, you stay in the localtesting branch the next time you do repo sync, and at the same time keep it up-to-date)

>git checkout localtesting (with the command above you create the new branch, with this one you actually go there)

>git fetch http://review.cyanogenmod.com/p/CyanogenMod/android_* && git cherry-pick FETCH_HEAD

If you do it like this, the cherry-pick will stay also when doing a repo sync. And by keeping the cherry-picks in their own branch (in the example above the branch 'localtesting'), you can always easily get back to the master branch and get rid off all the stuff you've done. I use the same approach if I change code in the source myself. When changing things in the master branch, it's easier to end up in problems/conflicts. And with these local branches you can always return to a clean state.

One thing to take care of: it can happen that a commit on review.cyanogenmod.com gets updated. In that case, I manually remove the cherry-picked commit and use the procedure above to download the latest version of the commit. There are different ways to do this, but I always use:

>cd ~android/system/cherrypicklocation

>git log -3 (then copy the change-ID of the last commit shown)

>git rebase -i copied-change-ID

you then come in nano (or the editor you've set as default editor). You can then remove the commit you want to remove. Then save&quit. The pick will then be removed.

After removing the old patchset, I download the latest version of the commit:

>git fetch http://review.cyanogenmod.com/p/CyanogenMod/android_* && git cherry-pick FETCH_HEAD

An alternative way to get rid of cherry-picks is to revert the cherry pick:

git revert <<change-ID of the commit you want to revert>>

But the advantage of the git rebase -i procedure is that your log of the branch stays clean (with git revert you will see the old cherry pick, the reverted old cherry pick, and the updated cherry pick (and with multiple updates this can become messy if you check the history of the branch using qgit). with git rebase -i you will only see the latest cherry pick).

If you don't remove a outdated cherry-picked commit and the updated commit gets merged, you will run into conflicts the next time you run repo sync.

Two tools which I often use are qgit (to see what's happening in different branches - it shows a timeline of the log and by clicking commits you can see the details) and meld (to compare files/folders). Meld is also useful to solve conflicts during cherry-picking (if I get a conflict message during a cherry pick I do:

>git mergetool

And then I can solve the conflict in meld using a three-way comparison between the old, the new and the combined file).

Just to be clear: what I write is not necessarily the only or best way to do it. But it works for me, I know all the things to type in the terminal by head and I am happy with it. So don't try to stick to tightly to how-to's by other people, just use them as a starting point and find you own way around :)