Can I use gerrithub.io to manage a github repo with existing branches?

Alex Nelson

unread,

Nov 6, 2014, 11:48:08 AM11/6/14

to Saša Živkov, Luca Milanesio, repo-d...@googlegroups.com

When I import a git repo managed by github into gerrithub.io shouldn't I see the branches associated with that git repo?

Is it possible to have gerrit manage a subset of the branches know to github?

Or do I have to manage all the branches in gerrithub.io if I want to manage the master branch in gerrithub.io?

In particular, I'd like to manage two branches from my github project using gerrithub.io.

I'd like to manage the (existing) master branch and the (existing) feature/headers branch.

With a clone from github, I see both of these branches:

% git branch -v -a

master b710859 [behind 4] Merge branch 'dev/elyons/strings' ...

remotes/origin/HEAD -> origin/master

...

remotes/origin/feature/headers 44604bf Original goal was to add testing for .....

remotes/origin/dev/gozen/bandwidth ada54ad Merge rem.....

....

With a clone from gerrit (I just now imported the github repo into gerrithub.io)

% git branch -v -a

* master 1763154 Revert "Revert "Stability fixes from origin/sandbox/elisamo/mdn_2.1_stability branch""

remotes/origin/HEAD -> origin/master

....

Maybe I need to patch the branch from github to gerrithub?

How would I manage that trick?

Luca Milanesio

unread,

Nov 7, 2014, 5:44:59 AM11/7/14

to Alex Nelson, Saša Živkov, repo-d...@googlegroups.com

On 6 Nov 2014, at 16:48, Alex Nelson <ane...@vidscale.com> wrote:

When I import a git repo managed by github into gerrithub.io shouldn't I see the branches associated with that git repo?

Is it possible to have gerrit manage a subset of the branches know to github?

Or do I have to manage all the branches in gerrithub.io if I want to manage the master branch in gerrithub.io?

Let me answer all the three questions at once :-)

You need to decide wether the "master" of your repo is GitHub or Gerrit: you can't have two masters managing the same repo or you would eventually having problems in keeping both in synch.

When you have Gerrit as your "main entry point", all is push to Gerrit and then it will be Gerrit's responsibility to replicate all the changes to GitHub on that repo.

The idea of having some GitHub branches "not known or visible" through Gerrit seems a bit odd to me: can you describe the overall use-case and purpose?

Maybe you just need a fork of the same repo instead of different branches.

In particular, I'd like to manage two branches from my github project using gerrithub.io.
I'd like to manage the (existing) master branch and the (existing) feature/headers branch.

Why don't you do a GitHub fork in this case?

You fork the repo, remove all the branches that you don't need and keep only the ones you want to manage through Gerrit.

Then you managed the forked repo with Gerrit, whilst the original is only managed through GitHub.

Does it make sense?

With a clone from github, I see both of these branches:
% git branch -v -a
master b710859 [behind 4] Merge branch 'dev/elyons/strings' ...
remotes/origin/HEAD -> origin/master

...
remotes/origin/feature/headers 44604bf Original goal was to add testing for .....
remotes/origin/dev/gozen/bandwidth ada54ad Merge rem.....
....

With a clone from gerrit (I just now imported the github repo into gerrithub.io)
% git branch -v -a
* master 1763154 Revert "Revert "Stability fixes from origin/sandbox/elisamo/mdn_2.1_stability branch""
remotes/origin/HEAD -> origin/master
....
<no remotes/origin/feature/headers>

Maybe I need to patch the branch from github to gerrithub?
How would I manage that trick?

Better to use the tools in the proper way than tricks ;-)

Halloween is over :-)

Luca.

Alex Nelson

unread,

Nov 7, 2014, 11:00:26 AM11/7/14

to Luca Milanesio, Saša Živkov, repo-d...@googlegroups.com

Luca,

Haha, you made me laugh out loud. :-)

Here is the use case:

Our master gets very little action. In particular, we have only 2 developers right now who push into master, and only rarely.

The bulk of the work gets done in various branches. One of the 2 special developers will eventually push a branch into master, but that is a rare event.

So that those 2 developers can "get used to using gerrit", we thought we have gerrit control the master branch and would be able to have gerrit mange a few test branches to try out the process. The plan would be to have those 2 developers okay the process and to move everybody to gerrit eventually. You may still say this can work, but gerrit will only see branches I tell it about. More likely you'll say that I must move wholesale to gerrit.

If you say that a wholesale move is required, then I'll have to re-negotiate the politics of forcing everyone to move to gerrit all at once.

I'm still left with not understanding why the branches didn't show up when I moved to gerrit?

I would have thought that the import would bring all the branches along as well? They showed up on github.com, why after the import did they not show on gerrithub.io? In other words, if we decide to move entirely to gerrit, I would expect that the process I used (import the github repo into gerrit) would bring along all the branches, but apparently that did not happen. Huh?

-Alex

Luca Milanesio

unread,

Nov 10, 2014, 12:03:02 PM11/10/14

to Alex Nelson, Saša Živkov, repo-d...@googlegroups.com

Hi Alex,

see my comments in-line.

On 7 Nov 2014, at 16:00, Alex Nelson <ane...@vidscale.com> wrote:

Luca,

Haha, you made me laugh out loud. :-)

Bringing happiness and laughter is one of the Gerrit Code Review side-effects ;-)

Here is the use case:

Our master gets very little action. In particular, we have only 2 developers right now who push into master, and only rarely.
The bulk of the work gets done in various branches. One of the 2 special developers will eventually push a branch into master, but that is a rare event.

So that those 2 developers can "get used to using gerrit", we thought we have gerrit control the master branch and would be able to have gerrit mange a few test branches to try out the process. The plan would be to have those 2 developers okay the process and to move everybody to gerrit eventually. You may still say this can work, but gerrit will only see branches I tell it about. More likely you'll say that I must move wholesale to gerrit.

Actually using Gerrit *without* using code-review (for the ones who are not using reviews yet) would be quite simple: just change the Git remote to point to Gerrit URL, it is a one-off activity.

The people that are "used to Gerrit" can use the code-review workflow, whilst the others can keep pushing directly to the branch.

The only important thing is that all the Team needs to use the Gerrit server URL and not pushing straight to GitHub.

If you say that a wholesale move is required, then I'll have to re-negotiate the politics of forcing everyone to move to gerrit all at once.

Unfortunately it is required :-(

The reason is simple: on GerritHub.io there is Gerrit with replication plugin pointing to GitHub.

If you have some people pushing to GitHub directly, without going through Gerrit, you'll end up in a situation where the replication would stop because GitHub will start diverging from Gerrit.

I'm still left with not understanding why the branches didn't show up when I moved to gerrit?

Possibly because they were created in GitHub directly and not through Gerrit?

I would have thought that the import would bring all the branches along as well? They showed up on github.com, why after the import did they not show on gerrithub.io? In other words, if we decide to move entirely to gerrit, I would expect that the process I used (import the github repo into gerrit) would bring along all the branches, but apparently that did not happen. Huh?

Mmm ... this is quite strange. I just imported one repo on my GitHub account and all the branches were imported as expected.

https://review.gerrithub.io/#/admin/projects/lucamilanesio/xml-avro,branches

Are you sure that branches existed at the time of the first import?

As I said, the replication works from Gerrit to GitHub (not the other way around) and if you create a branch on GitHub after the initial import, it wouldn't be visible in Gerrit out-of-the-box.