Repo start and repository branch name

Source: Internet
Author: User
Tags xml example using git

20130111
Repo and git

4.1 Project
Repo init-u gitosis@XXXXroid.git.xxxxxxxxxx.com.cn: Android/platform/manifest. Git-B xxxxroid4.1 -- repo-url = gitosis@XXXXroid.git.xxxxxxxxxx.com.cn: Tools/Repo. Git
The above command selects the branch of manifest. XML as xxxxroid4.1 during repo init. However, this does not guarantee that after you repo sync, you can switch all the repositories to the xxxxroid4.1 branch. Because not every warehouse has this branch !!!!
I made a mistake and thought that all warehouses have branches with the same number of corresponding names! So I always like to use it after repo sync.
Git checkout -- track remotes/Korg/xxxxroid4.1-B xxxxroid4.1
To traverse all the repositories based on the manifest. xml file and switch the branches to the same one. It was always possible. But today there is a problem. The reason is that some warehouses do not have any branch remotely. That is, not every repository needs to switch to the same branch name.
For a project, the branch names of remote warehouses tracked by each of its warehouses are not completely uniform! The corresponding branch used by a repository in a project is specified in manifest. xml!
Let's look at a manifest. xml example:
<? XML version = "1.0" encoding = "UTF-8"?>
<Manifest>

<Remote name = "Korg"
Fetch= "gitosis@XXXXroid.git.xxxxxxxxxx.com.cn: Android /"
Review = "review.source.xxxxxxxxxx.com/gerrit/"/>
<Default revision = "xxxxroid4.1" specifies the default branch name.
Remote = "Korg"
Sync-j = "4"/>

<Project Path = "build" name = "platform/build">
<Copyfile src = "Core/root. mk" DEST = "makefile"/>
</Project>
<Project Path = "Abi/CPP" name = "platform/Abi/CPP"/>
<Project Path = "Bionic" name = "platform/bionic"/>
<Project Path = "bootable/bootloader/legacy" name = "platform/bootable/bootloader/legacy"/>
<Project Path = "bootable/diskinstaller" name = "platform/bootable/diskinstaller"/>
<Project Path = "bootable/recovery" name = "platform/bootable/recovery"/>
<Project Path = "CTS" name = "platform/CTS"/>

The above projects are consistent: path specifies the local warehouse location, name specifies the remote warehouse location, the local warehouse will track the remote xxxxroid4.1 branch by default.
Let's take a look at the following: (it is from the same manifest. XML as above)
<Project Path = "packages/apps/10086cn" name = "platform/packages/apps/10086cn" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/appbackup" name = "platform/packages/apps/appbackup" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/audioprofile" name = "platform/packages/apps/audioprofile" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/monternet" name = "platform/packages/apps/monternet" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/myfavorites" name = "platform/packages/apps/myfavorites" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/xxxxnote" name = "platform/packages/apps/xxxxnote" revision = "xxxxroid_own_copyright"/>
<Project Path = "packages/apps/validationtools" name = "platform/packages/apps/validationtools" revision = "xxxxroid_own_copyright"/>

In addition to specifying the name and path, these projects also specify the revision. This revision is the default status of these repositories after sync, that is, the xxxxroid_own_copyright branch of the remote repository is tracked. If this parameter is not specified, the default branch name xxxxroid4.1 is used.

Repo init-B xxxxroid4.1 switch manifest to the branch you want
Repo sync-J4-Q synchronization code

Repo start local-0113 -- all create branches based on manifest. xml

Next, we will use repo start to create branches in each warehouse and ensure that each branch is connected to the corresponding remote branch. Do not use repo forall as I previously did. I have already verified that repo start can really make the local branch different from the remote branch based on the information in manifest. xml! Here is my verification.

Apuser @ yaochuanliubt :~ /Mywork/403-akm $ repo start local-0113 -- all
Starting local-0113: 100% (248/248), done.
Apuser @ yaochuanliubt :~ /Mywork/403-akm $ CD kernel/
Apuser @ yaochuanliubt :~ /Mywork/403-akm/kernel $ git Branch
* Local-0113
Apuser @ yaochuanliubt :~ /Mywork/403-akm/kernel $ cat. Git/config
[Core]
Repositoryformatversion = 0
Filemode = true
[Remote "Korg"]
Url = gitosis@XXXXroid.git.xxxxxxxxxx.com.cn: Android/kernel/common. Git
Review = review.source.xxxxxxxxxx.com/gerrit/
Projectname = kernel/common
Fetch = + refs/heads/*: refs/remotes/Korg /*
[Branch "Local-0113"]
Remote = Korg
Merge = xxxxroid4.0.3 _ vlx_3.0/. Here is/

Apuser @ yaochuanliubt :~ /Mywork/403-akm $ CD Packages/apps/10086cn/
Apuser @ yaochuanliubt :~ /Mywork/403-akm/packages/apps/10086cn $ git Branch
* Local-0113
Apuser @ yaochuanliubt :~ /Mywork/403-akm/packages/apps/10086cn $ cat. Git/config
[Core]
Repositoryformatversion = 0
Filemode = true
[Remote "Korg"]
Url = gitosis@XXXXroid.git.xxxxxxxxxx.com.cn: Android/platform/packages/apps/10086cn. Git
Review = review.source.xxxxxxxxxx.com/gerrit/
Projectname = platform/packages/apps/10086cn
Fetch = + refs/heads/*: refs/remotes/Korg /*
[Branch "Local-0113"]
Remote = Korg
Merge = xxxxroid_own_copyright/. Here is another one! /
Apuser @ yaochuanliubt :~ /Mywork/403-akm/packages/apps/10086cn $
Apuser @ yaochuanliubt :~ /Mywork/403-akm/packages/apps/10086cn $

Therefore, do not use the repo forall method to create a branch in the future!

In addition, when you use git checkout -- track remotes/Korg/xxxxroid4.1-B xxxxroid4.1 to create a local branch, the remote branch of the trail is specified, if you execute git status after a new change in the local commit, the similarities and differences between your local branch and the number of remote branches you track will be displayed, however, if you use repo start to build a local branch, although it also traces a specific remote branch, it does not show the similarities and differences between local and remote branches when I use git status, this is unpleasant. Because I always need to execute repo in the root directory of the project.
Forall-p-C git status is used to traverse all the repositories of the entire project and find the local repository that I have submitted. After all, my modifications to a problem may involve multiple repositories. If I do not perform this check, I may forget the modification of a repository during push, resulting in incomplete code on the server. I am a perfect person, you know.

Topic branches are typically lightweight branches that you create locally and that have a name that is meaningful for you. they are where you might do work for a bug fix or feature (they're also called feature branches) that is expected to take some time
To complete.

Another type of branch is the "remote branch" or "remote-tracking branch ". this type of branch follows the development of somebody else's work and is stored in your own repository. you periodically update this branch (using git fetch) to track what is happening
Elsewhere. When you are ready to catch up with everybody else's changes, you wocould use git pull to both fetch and merge.

I have also seen another kind of branch which is essential a completely separate tree of files in the same repository. for example, the GIT repository itself contains heads named man and HTML that contain entirely different content from the master branch.
I don't know what these types of branches are usually called.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.