Repo Without Gerrit

[Matt Oakes]

Hi,

I'm working with the android source code and making modifications to various parts of it. It's with a small team (5 people max), so I think using Gerrit is a bit wasteful as we do code review in person.

So far I've created a mirror of the AOSP code using the command:

repo init -u https://android.googlesource.com/mirror/manifest --mirror

repo sync

This goes fine and I now have a local copy of all the source. It's in a directory called AndroidMirror.

I then create another directory called Code and run:

repo init -u <path-to-AndroidMirror>

repo sync

This also goes fine and I've now got a place to work on my modifications.

I create a new branch with:

repo start BranchName frameworks/base

and then commit my changes. When I come to merge I run:

git checkout -b master

git merge BranchName

git push aosp master

This also works fine. This is the point that I'm not sure that what I'm doing is right. This is because when I run repo sync on AndroidMirror and it has some changes to frameworks/base, and then run repo sync on Code, it will wipe out my changes. I can't remember the exact message, but it's something like 2 commits discarded.

I'm sure I'm doing something wrong with my workflow, but I can't figure it out.

Like I said, we'd prefer not to use Gerrit, but if that's not possible is there a way to make it as easy as possible to bypass it. I've tried to set it up but it seems more complicated than we need for such a small team.

Any help would be greatly appreciated.

Thanks in advance!

Matt

[Magnus Bäck]

On Thursday, December 15, 2011 at 10:50 CET,
Matt Oakes <ma...@ribot.co.uk> wrote:

> I'm working with the android source code and making modifications to
> various parts of it. It's with a small team (5 people max), so I think
> using Gerrit is a bit wasteful as we do code review in person.

Have you actually tried? Many organizations (including us) use Gerrit
and similar systems for all development regardless of team size.

[...]

> This also works fine. This is the point that I'm not sure that
> what I'm doing is right. This is because when I run repo sync on
> AndroidMirror and it has some changes to frameworks/base, and then
> run repo sync on Code, it will wipe out my changes. I can't remember
> the exact message, but it's something like 2 commits discarded.
>
> I'm sure I'm doing something wrong with my workflow, but I can't
> figure it out.

If you want to store your local AOSP patches on your server you must
do it on a separate branch. There was a recent discussion about this
exact topic on the android-building mailing list (http://goo.gl/nNnPQ),
in which I wrote a rather long description that I think will be helpful
for you (apparently I should've cross-posted to repo-discuss).

> Like I said, we'd prefer not to use Gerrit, but if that's not possible
> is there a way to make it as easy as possible to bypass it. I've tried
> to set it up but it seems more complicated than we need for such a
> small team.

The key is that you don't want to make local changes to the same
branches that you mirror from upstream. This is true regardless of
whether you use Gerrit.

--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

[Matt Oakes]

Cool! Thanks for the answer. Made a lot of sense.

Just to double check I understand, when you say do work on a new branch do you mean run a command like:

git checkout -b MyProduct/Branch

In the git repository where you will be doing work on? How would you then go about updating this branch, keeping my changes, but merging in the new changes on the aosp branch. Would something like:

git rebase aosp/Branch

do it?

Sorry if these are stupid questions. I've just been confusing myself for a while now and thought it was time to ask someone. Thanks for all the help so far!

Matt

[Brad Larson]

On Dec 15, 2:43 pm, Magnus Bäck <magnus.b...@sonyericsson.com> wrote:
> On Thursday, December 15, 2011 at 10:50 CET,

>      Matt Oakes <m...@ribot.co.uk> wrote:
>
> > I'm working with the android source code and making modifications to
> > various parts of it. It's with a small team (5 people max), so I think
> > using Gerrit is a bit wasteful as we do code review in person.
>
> Have you actually tried? Many organizations (including us) use Gerrit
> and similar systems for all development regardless of team size.

I've been known to use Gerrit for a team size of 1 :)
Looking over the code in Gerrit's diff view will sometimes make me
notice things I missed with git diff or gitk. I'd encourage you to
give Gerrit a try, you might find it to be faster/more efficient than
in-person code reviews.

[Matt Oakes]

Possibly. However there's been a bit of work going on to ditch tools like this so we interact more with each other and have interesting conversations. I might still give it a go though. Either way I still couldn't get it to work quite right with regards to changes being overritten.

Maybe a bit more digging is needed...

[Magnus Bäck]

On Friday, December 16, 2011 at 11:21 CET,
Matt Oakes <ma...@ribot.co.uk> wrote:

> Cool! Thanks for the answer. Made a lot of sense.
>
> Just to double check I understand, when you say do work on a new
> branch do you mean run a command like:
>
> git checkout -b MyProduct/Branch
>
> In the git repository where you will be doing work on?

Yes, if MyProduct/Branch is the name of the remote branch that you
wish to track. That branch would be based on the original AOSP branch.
You have three layers of branches here; the AOSP remote branch (A), the
remote branch containing your AOSP patches (B), and finally your local
branch (C) where you commit your changes prior to pushing to B on the
server.

> How would you then go about updating this branch, keeping my changes,
> but merging in the new changes on the aosp branch. Would something
> like:
>
> git rebase aosp/Branch
>
> do it?

Yes, it would certainly work but rebasing a branch that you share with
other people is generally not recommended and shouldn't be done unless
you and everyone else know what's being done. You should most likely be
merging the changes instead. It could look something like this:

git checkout -b mymerge origin/your-companys-aosp-patches
git merge origin/aosp/master
git push origin mymerge:your-companys-aosp-patches

Now, a potential problem with a merge workflow like this is that
your patches may be reverted, reapplied, merged upstream etc so that
the history of your branch gets rather messy over time. What you could
do is periodically start a new branch off of the AOSP branch and clean
things up (using the interactive rebase feature helps a lot). You may
have natural points in time when this is appropriate, e.g. when you
start development of new products or just new major releases.

[Matt Oakes]

Perfect!

Thank you! Got it all set up now.

Thanks :)