After repo sync, git status shows "Not currently on branch" and manifest file

[Rafeah Rahim]

Hi All,

Another newbie repo question which I hope someone can enlighten me as I have been goggling for the answer and I still don't seem to get it. :(

After I sync the code from my local AOSP mirror,
$repo init -u ssh://<aosp_mirror_server>/aosp_mirror/manifest.git -b <codebranch>
$repo sync

I check all the git repositories and it all shows not on branch.
$repo forall -c 'echo $REPO_PROJECT;git status'
device/common
# Not currently on any branch.
nothing to commit (working directory clean)
....

Q1/ Why does each repo project shows "Not currently on any branch."? I assume it will checkout the branch based on the manifest.xml file revision field information but it seem it is not.

Q2/ If I use repo start <branch_name>? Where will the new topic branch starts for each project?

What I am trying to achieve here is, I want to create a new branch based on the manifest file information.
Then push this new branch to the local mirror so that other developers can start doing development and push their changes to that branch.

It is this good way to do it?
Also, after I push the new branch to the AOSP mirror, how do I update the manifest file so that the other developer will start using my new branch?

Thanks.

[Magnus Bäck]

On Wednesday, April 03, 2013 at 04:31 EDT,

Rafeah Rahim <rafeah....@gmail.com> wrote:

> Another newbie repo question which I hope someone can enlighten me as
> I have been goggling for the answer and I still don't seem to get it.
> :(
>
> After I sync the code from my local AOSP mirror,
> $repo init -u ssh://<aosp_mirror_server>/aosp_mirror/manifest.git -b
> <codebranch>
> $repo sync

Weird Git URL. I had expected platform/manifest or
someprefix/platform/manifest.

> I check all the git repositories and it all shows not on branch.
> $repo forall -c 'echo $REPO_PROJECT;git status'
> device/common
> # Not currently on any branch.
> nothing to commit (working directory clean)
> ....

(You may find 'repo status' useful.')

> Q1/ Why does each repo project shows "Not currently on any branch."?
> I assume it will checkout the branch based on the manifest.xml file
> revision field information but it seem it is not.

Yes it does, but it doesn't create a local branch for you. When you
check out a remote branch you'll end up with a detached head (since
you can't make commits on the remote branch anyway).

> Q2/ If I use repo start <branch_name>? Where will the new topic branch
> starts for each project?

It'll be based on the current commit pointed to by the manifest.

> What I am trying to achieve here is, I want to create a new branch
> based on the manifest file information.
> Then push this new branch to the local mirror so that other developers
> can start doing development and push their changes to that branch.
>
> It is this good way to do it?

Unless you actually want to make commits on the new branch you don't
have to create any local branches. You can just push the remote branch
(which gets resolved to a commit) to the desired branch on the server:

git push ssh://hostname/project/name origin/master:refs/heads/yourmaster

Doing this for all gits becomes:

repo forall -c 'git push ssh://hostname/$REPO_PROJECT \
origin/master:refs/heads/yourmaster'

(If you can push to the same URL as you pull you can replace the ssh://
URL with the name of the remote, probably 'aosp'. Some sites use
asymmetric URLs where clients pull from read-only slaves but push all
changes to the master server. Even if you don't need this now you might
want to consider making it an easy transition in the future by not
hardcoding in too many places, including the brains of your users, that
your pull and push URLs are identical.)

Now, you shouldn't assume that origin/master is the branch listed for
all projects in the manifest. At times in the past some projects have
used different branches by overriding the 'revision' attribute in the
manifest. If that's the case now you need to decide what to do about it.
Do you want to use the same internal development branch everywhere, or
do you want your branch name to match that of the upstream branch?
Anyway, $REPO_RREV will probably be useful here.

> Also, after I push the new branch to the AOSP mirror, how do I update
> the manifest file so that the other developer will start using my new
> branch?

cd .repo/manifests
sed -i 's/<default revision="master"/<default revision="yourmaster"/' \
default.xml
git commit -a -m 'Changed default revision from master to yourmaster'
git push ssh://hostname/platform/manifest HEAD:refs/heads/yourmaster

Or why not push to refs/for/yourmaster to have someone review your
change?

As always, I recommend keeping upstream branches in a namespace separate
from your own branches, in this case e.g. by prefixing the AOSP branches
with 'aosp/'. You could do it the other way around too and have your own
branches under e.g. 'yourcompanyname/', but since that assumes you never
have more than one upstream I favor the first option.

--
Magnus Bäck
ba...@google.com

[Rafeah Rahim]

Thank Magnus for your reply.

"Unless you actually want to make commits on the new branch you don't
have to create any local branches. You can just push the remote branch
(which gets resolved to a commit) to the desired branch on the server: "

Actually, I am not doing any commits.
The plan is to define a new branch for my developers to start the sync and start working on the new branch.
Hence, any new commits done by the developers will be pushed to the new branch.

As most project's revision field in the manifest file consist of SHA1 number, how can we create a new branch using the $REPO_RREV defined in
Will this work?
    repo forall -c 'git push ssh://<aosp_mirror_server>/aosp_mirror/$REPO_PROJECT \
        origin/$REPO_RREV:refs/heads/working/project1_int'

Where the target branch is working/project1_int

Or it is just better to execute:
     $repo start working/project1_int
     $repo forall -c 'git push -u -v ssh://<aosp_mirror_server>/aosp_mirror/$REPO_PROJECT working/project1_int'

"As always, I recommend keeping upstream branches in a namespace separate
from your own branches, in this case e.g. by prefixing the AOSP branches
with 'aosp/'. You could do it the other way around too and have your own
branches under e.g. 'yourcompanyname/', but since that assumes you never
have more than one upstream I favor the first option. "

Sorry, what you mean by "more than one upstream"? Does it mean multiple branch tracking a different remote? i.e. branch1 --> origin/master, branch2---> origin2/master ?

Actually, I am planning to keep the AOSP branches as it is and any new branches under <mycompanyname>/ as per your 2nd option, this is not recommended?

My set up is, I have as aosp_mirror which will regular get updates from aosp server.
This aosp_mirror will be used by developers to download their code to their local workspace.

For any code change that needs to be reviewed, the developer will need to push their code change to gerrit2 to <mycompanyname>/dev branch.
Once code is approved, gerrit2 <mycompanyname>/dev will be pushed to aosp_mirror

For those code that does not need to reviewed will be pushed to working/project1_int in aosp_mirror .
So technically, I have 2 working branch on the aosp_mirror, 1 is the working/project1_int for developers to exchange code  and the other <mycompanyname>/dev is for official change releases.

Do let me know your thoughts if I am going the wrong way.
Thanks a lot!

[Magnus Bäck]

On Wednesday, April 03, 2013 at 23:42 EDT,

Rafeah Rahim <rafeah....@gmail.com> wrote:

> > Unless you actually want to make commits on the new branch you don't
> > have to create any local branches. You can just push the remote
> > branch (which gets resolved to a commit) to the desired branch on
> > the server:
>
> Actually, I am not doing any commits.
> The plan is to define a new branch for my developers to start the sync
> and start working on the new branch.
> Hence, any new commits done by the developers will be pushed to the
> new branch.

That's what I suspected. Then you don't have to create a local branch.

> As most project's revision field in the manifest file consist of SHA1
> number, how can we create a new branch using the $REPO_RREV defined in
> Will this work?
> repo forall -c 'git push
> ssh://<aosp_mirror_server>/aosp_mirror/$REPO_PROJECT \
> origin/$REPO_RREV:refs/heads/working/project1_int'

No, drop the origin/ part. If the manifest you're basing your work on
contains SHA-1s as the revisions of the projects it's the SHA-1s you
need to push, and you'll find them in $REPO_RREV.

> Where the target branch is working/project1_int
>
> Or it is just better to execute:
> $repo start working/project1_int
> $repo forall -c 'git push -u -v
> ssh://<aosp_mirror_server>/aosp_mirror/$REPO_PROJECT working/project1_int'

That should work equally well. Actually, if the manifest contains a mix
of SHA-1s, tags, and branches this method will work better. Or, hmm,
you could use $REPO_LREV to translate all revisions into SHA-1. That's
probably the most elegant solution.

> > As always, I recommend keeping upstream branches in a namespace
> > separate from your own branches, in this case e.g. by prefixing the
> > AOSP branches with 'aosp/'. You could do it the other way around too
> > and have your own branches under e.g. 'yourcompanyname/', but since
> > that assumes you never have more than one upstream I favor the first
> > option.
>
> Sorry, what you mean by "more than one upstream"? Does it mean multiple
> branch tracking a different remote? i.e. branch1 --> origin/master,
> branch2---> origin2/master ?

Yes. Currently your only upstream is AOSP, but what if you in addition
want to mirror android-x86.org, CodeAurora, or CyanogenMod?

> Actually, I am planning to keep the AOSP branches as it is and any new
> branches under <mycompanyname>/ as per your 2nd option, this is not
> recommended?

Personally I don't recommend it because

- it becomes awkward with more than one mirrored upstream, and
- 'companyname/branchname' is more typing than 'branchname',
and users will be typing your branch names more often than
the upstream branch names,

but it's mostly a matter of taste.

> My set up is, I have as aosp_mirror which will regular get updates
> from aosp server.
> This aosp_mirror will be used by developers to download their code to
> their local workspace.
>
> For any code change that needs to be reviewed, the developer will need
> to push their code change to gerrit2 to <mycompanyname>/dev branch.
> Once code is approved, gerrit2 <mycompanyname>/dev will be pushed to
> aosp_mirror
>
> For those code that does not need to reviewed will be pushed to
> working/project1_int in aosp_mirror .
> So technically, I have 2 working branch on the aosp_mirror, 1 is the
> working/project1_int for developers to exchange code and the other
> <mycompanyname>/dev is for official change releases.

Using branches to separate code that's reviewed and code that isn't
reviewed is atypical and doesn't appear to make sense. What problem
are you trying to solve? I suggest you start with one branch. If you
need to slow down the rate of change as a release approaches, create
a release branch. But maybe that's what you just described. No special
provisions are necessary for developers to exchange code. They exchange
code through the branches on which development takes place.

--
Magnus Bäck
ba...@google.com

[Raf]

Thanks Magnus for your advice. =)

The reason why I wanted a separate branch is because we are doing collaboration with developers from other company and hence they are not on my LDAP server and my gerrit server is configured to authenticate via ldap. So to overcome this, the reason of another branch where users not on gerrit can push their changes to working/int branch on aosp mirror.