I have downloaded whole working tree with the following command:
repo init -u https://android.googlesource.com/platform/manifest
repo sync -j8
After syncing successfully, I want to switch working tree to android 2.3.7.
You see I didn't specify branch with "-b" parameter when "repo init".
So I guess all tag info should be downloaded and I can easily switch to android 2.3.7 with the following command:
repo forall -c git checkout android-2.3.7_r1
But it produces many errors like:
error: pathspec 'android-2.3.7_r1' did not match any file(s) known to git.
So how can I switch to android 2.3.7 without "repo init -b android-2.3.7_r1" and "repo sync" again?
You cannot solve this problem using repo forall.
Lets assume for certainty that your current Android tree is clean - no local changes or commits, i.e. repo status shows nothing.
To properly switch Android version, all you need to change is branch for your manifest repository. First determine the available branches with manifests for the different Android versions:
cd $ANDROID_ROOT
cd .repo/manifests
git branch -av # see all available branches on origin
Select a version and
cd $ANDROID_ROOT
repo init -b <my_selected_android_version>
Such selective repo init with -b (without -u) will only update manifest branch and will not otherwise touch your tree.
Now, simply sync it:
repo sync -j8
and some time later, your Android tree will switch to another version.
Speed of this operation is mostly determined by how much default.xml manifest file differs between old and new Android versions - because if some git repository was added in new manifest, it will spend time cloning it. And if some repository was removed, if will actually blow it away.
But, by and large, this method is still much faster than initializing brand new Android tree from scratch.
if the branch you are in and the branch you will switch to has the same manifest.xml file, then you can use the following commands to do that.
repo forall -c git fetch aosp --tags
repo forall -c git checkout -b john5.1.1_r14_api22 android-5.1.1_r14
also see details in
http://johnliao52.github.io/2016/03/27/git-repo-skills.html
Related
We're working with a SoM for an android embedded project. It involves writing drivers, designing apk and making an android customization from the AOSP.
With repo commands we downloaded many repositories (AOSP, NXP and SoM's manufacturer)
We started working in a develop branch:
repo forall -c 'git checkout -b <dev_branch_topic>'
We also tried with:
repo start <branch/topic>
(I'm not really sure of the difference between using repo forall .. or repo start for this goal)
We designed our manifest that includes the SoM's manufacturer manifest, at the same time it includes an AOSP manifest (that calls NXP and AOSP repositories)
Is there a "repo forall -c ..." command to push my own modified AOSP project to a remote GitHub repository?
Do we need first to create an empty folder for each repository that we would like to backup in our GitHub account?
Which repo command lets us change every "remote url field" inside the git config's files? We assume that getting in every project and changing it manually is not viable.
I'm trying to build custom rom for my device from CM source.I'm following this guide to build:
https://wiki.cyanogenmod.org/w/Build_for_quark
I'm using this command to sync the source.
repo init -u https://github.com/CyanogenMod/android.git -b cm-12.1
During download i can see other branches like 7,8,9,10,11,12.Is there any way to download only current branch (12.1)?
The repo sync command is same as git clone when used without any flags, that means you are simply downloading all the branches from all the repositories defined in the manifest file (visit this and see the default.xml file).
To download only the current branch that is cm-12.1, use the -c flag while using the repo sync command. Note that the Android source is made from many projects and is a huge download when you are syncing for the first time.
So your commands should be:
repo init -u https://github.com/CyanogenMod/android.git -b cm-12.1
repo sync -c
For a better understanding of how repo tool works just read this article.
I hope this helps.
I'm trying to learn Embedded Android from the book with the same name. And the author suggested working with AOSP gingerbread branch. So I followed to download the source:
$ repo init -u https://android.googlesource.com/platform/manifest.git
-b gingerbread
$ repo sync
But it's taking too long. Also from the output, it seems to me like it's also downloading source code from other branches (I see android-5.....) which is not what I want. I'm wondering if that's the reason why it takes so long.
Has anybody had the same problem? Please give me a suggestion! Thanks!
AOSP is a multi-gigabyte download so there's not that much you can do. However, passing the -c/--current-branch option to repo sync causes Repo to tell Git to only fetch the branch you really need instead of all branches of each repository. With an old release like Gingerbread this should theoretically be quite beneficial. However, Repo seeds the repositories with Git bundles that it downloads via HTTP, and the bundle files aren't affected by the -c option. Using --no-clone-bundle disables the bundle files. Hence the following Repo command should yield the smallest download:
repo sync -c --no-clone-bundle
(Keep in mind that Gingerbread is a several year old release. It won't work out of the box on a lot of recent hardware.)
You should use this commands:
Example: for my personal AOSP Repo,
repo init --depth=1 -u https://github.com/zawzaww/aosp-android.git -b android-8.1.0
and then,
repo sync -f --force-sync --no-clone-bundle --no-tags -j$(nproc --all)
You can learn more on my GitHub Repo
repo init --depth 1
This is another option that might improve sync speed, as it should only download the latest version of the repos.
See also: https://superuser.com/questions/603547/how-can-i-limit-the-size-of-the-android-source-i-need-to-download-with-repo-syn
Here are my full test commands: How to compile the Android AOSP kernel and test it with the Android Emulator?
repo sync -c --no-tags --no-clone-bundle -j2
Shortens my sync times greatly.
I'm very new at GIT, apologize if this is a basic question however I couldn't seem to find a similar situation after searching google and stackoverflow. Here's my scenario:
I have a git folder with the latest commit version that I do NOT perform any commit (I won't do any changes in the code in my local directory). Other people performs the commit on their computer, I just need to get a specific commit version, copy it to a working directory and build code. I'm planning to make a program to automatically perform these steps in repeated cycle everyday. Steps summarized below:
Get the latest commit in repo_folder
Go back to old commit version
Copy to a work_folder
Then build code in work_folder
I'm not sure if these steps are the correct/best way to do it. Also, how can I perform #2 correctly and how to make sure my program have retrieved the correct commit version? Is #3 necessary? Or can I just build code directly in repo_folder (might modify some files after build), then afterwards perform git command to get the latest commit version again?
Here's my steps actual steps
1. Get the latest commit in repo_folder
repo init -u ssh://username#git.aaa.com:1234/manifest.git -b branch -m file.xml
repo sync
After getting to the latest repo, I search through the logs and perform git reset --hard
2. Go back to old commit version
cd .repo/manifests
COMMITHASH=git log --grep=$keyword | head -1 | cut -d' ' -f2
git reset --hard $COMMITHASH
cp file.xml new_file.xml
repo init -m new_file.xml
After this command, I'm not sure how to check if my current version is correct.
Steps 3 and 4 just simple copy and build commands not related to this question.
cp -r repo_folder/folder1 work_folder/folder1
cp -r repo_folder/folder2 work_folder/folder2
run build.bat
Just clone your local master to a new directory and then checkout to the version that you currently need in that one:
No copying, no mucking about.
git clone -l /path/to/master /path/to/working
cd /path/to/working
git checkout -f REV_OR_BRANCH_ID
If you have any generated files such as objects it is a good idea to clean them up - such as with make clean after a checkout.
from then on you can:
cd /path/to/working
git pull
git checkout -f REV_OR_BRANCH_ID
I feel I have a pretty good understanding of git, but when it comes to the repo command, I get lost. I've read about the repo command, but I'm still not sure how it ties everything together.
My biggest question is can I change my current branches from gingerbread to ICS and possibly back?
I see the command:
repo init -u https://android.googlesource.com/platform/manifest
From my understanding, this will create a repo with the master branch. If I want to specify the branch, I can do:
repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
The download is about 8GB, I believe, so I don't want to have to blow my repo away if they share code. is there a way to switch branches in repo?
If you run repo init a second time with a different branch, you can simply repo sync and it will not download the entire source code again.
The second time you run repo init, just run it as
repo init -b different_branch
You don't need to provide the -u parameter again.
The repo -b parameter specifies the branch of the .repo/manifests git repository that should be checked out. The default.xml file in this repository defines which branch each of the other git repositiories (projects) should be on.
It seems that repo is written in such a way that if you check out another manifest branch are repo sync again it will pull all the code again over the network.
You can run repo forall -c 'git checkout branch_name' which will checkout the specified branch for all projects that are declared in your current manifest but if there are projects added/removed between gingerbread and ics (which there are), then you won't get the code for these projects.
Running git checkout branchname in the .repo/manifests repository then running repo sync may enable you to save some network overhead.
Otherwise, due to the limitations of repo, the only real way to do it is to maintain two working copies of the aosp or be prepared to re-sync.