Gerrit with external repository

[Rafał Wołoszyn]

Hi all,

As far as I know Gerit uses its own Git repository, is it possible to use Gerrit only as review tool with external repository ? 

Best regards,

Rafal

[Alex Blewitt]

No. 

Sent from my iPhat 6

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rafał Wołoszyn]

Ok. So maybe this will be nice feature for gerrit. To let people use gerrit as review on their already existing repos ?

[Gaurav Negi]

I also tried it, to much mess and too complicated and then donot work in all cases.

Sent from my iPhone

[Luca Milanesio]

There is a way of using it on existing repos:

a) Use Gerrit as first-point of contact for push

b) Use Gerrit for code-review

c) Configure replication from Gerrit to existing repos

d) Keep on using the existing repos for pulls / fetch

See an example on how we do this with GitHub at:

https://www.youtube.com/watch?v=jeWTvDad6VM

HTH

Luca.

[Gaurav Negi]

Use google code review Rietveld or Phabricator in that case.

Sent from my iPhone

--

[Jonathan Nieder]

Luca Milanesio wrote:

There is a way of using it on existing repos:

a) Use Gerrit as first-point of contact for push

b) Use Gerrit for code-review

c) Configure replication from Gerrit to existing repos

d) Keep on using the existing repos for pulls / fetch

See an example on how we do this with GitHub at:

https://www.youtube.com/watch?v=jeWTvDad6VM

Yep, I've seen this kind of workflow work well.

Gerrit wants to be the only user that writes to the branch it controls (although it can tolerate some pushes behind its back to the repository on the same machine). It is acting like a human maintainer, so to speak.

What if the existing repo is controlled by a completely separate project? you might ask. E.g. what if you want to use Gerrit to develop a patched Linux kernel (the Linux kernel open source project doesn't use gerrit)? I've seen two approaches:

 a. Replicate the existing repo to a machine running Gerrit. Using Gerrit for code review, but don't ever Submit --- instead, once the patch is in good shape, send it upstream and click Abandon in Gerrit.

 b. Replicate refs/heads/master from the existing repo to refs/heads/upstream on a machine running Gerrit. Use Gerrit as usual to develop refs/heads/master. When you want to pull in the latest changes from upstream, run

  git fetch origin

  git checkout origin/master

  git pull origin upstream

  git push origin HEAD:refs/for/master

This creates a change representing your intent to get the latest changes from upstream. The diff represent any changes you made to the automatic merge --- in other words, it says how you resolved conflicts --- so the diff will usually be empty. The change can be reviewed and submitted as usual to incorporate the latest upstream changes into master.

Hope that helps,

Jonathan

[Luca Milanesio]

On 2 Jun 2016, at 20:33, Jonathan Nieder <j...@google.com> wrote:

Luca Milanesio wrote:

There is a way of using it on existing repos:

a) Use Gerrit as first-point of contact for push

b) Use Gerrit for code-review

c) Configure replication from Gerrit to existing repos

d) Keep on using the existing repos for pulls / fetch

See an example on how we do this with GitHub at:

https://www.youtube.com/watch?v=jeWTvDad6VM

Yep, I've seen this kind of workflow work well.

... and over 10K people on GerritHub.io are using it :-) ... plus all the OpenStack folks on review.openstack.org and possibly many others ;-)

Luca.

[Gaurav Negi]

Luca, this way is sort of Gerrit hosting GIT at repos.

Just that GIT repos (inside Gerrit) are replicated outside Gerrit also.

I think the original question was GIT repos are outside Gerrit and opt-in way for Gerrit to be used just for code review. 

Sent from my iPhone

[Luca Milanesio]

On 2 Jun 2016, at 21:00, Gaurav Negi <gaura...@gmail.com> wrote:

Luca, this way is sort of Gerrit hosting GIT at repos.

Just that GIT repos (inside Gerrit) are replicated outside Gerrit also.

I think the original question was GIT repos are outside Gerrit and opt-in way for Gerrit to be used just for code review. 

... and the answer is YES as Gerrit is a pre-commit review. 

Of course whilst the code is under review is managed by Gerrit on his internal Git repo.

When the code gets merged, the replication plugin will push it to its target repo.

On GerritHub people use it only for code-review, whilst all the rest of the operations are on GitHub.

It is a different way of using Gerrit, still valid IMHO.

Some of the people decide as well to do Code Review through Gerrit *only* for some branches, whilst the others are still managed directly on GitHub.

As long as the branches are separate and segregated, there isn't any problem with the co-hexistence of the two.

Luca.

[Rafał Wołoszyn]

So generally it is possible. Only one disadvantage of this approach is that source code will be duplicated, in Gerrit repo an external one.

Since people already using it approach so maybe it will be nice to have that kind of feature in Gerrit to choose which repo will be used during 

Gerrit installation ? 

On Thursday, 2 June 2016 19:26:53 UTC+2, Rafał Wołoszyn wrote:

[Luca Milanesio]

On 2 Jun 2016, at 21:17, Rafał Wołoszyn <woloszy...@gmail.com> wrote:

So generally it is possible. Only one disadvantage of this approach is that source code will be duplicated,

Gerrit is a pre-commit review system, that means that the review work is like that:

a) John pushes the code for review to Gerrit

b) Tom, Alice do the review and provide feedback

c) John rework the code, amend the commit and pushes the code again to Gerrit

d) Tom, Alice give the green light

e) Ben can validate the code and submit upstream

f) ... the code eventually lands to its target branch.

Only at step f) the code is on its target repo / branch, but not before that.

Other code-review systems (e.g. ReviewBoard, Crucible) do the opposite: let the people push the code to Git and then give a "whiteboard" to do the review.

This is why you cannot use Gerrit *without* having "somewhere" to store the code whist is under review.

Gerrit uses a specific Git namespace for this "somewhere" called refs/changes/*.

Luca.

in Gerrit repo an external one.

Since people already using it approach so maybe it will be nice to have that kind of feature in Gerrit to choose which repo will be used during 

Gerrit installation ? 

On Thursday, 2 June 2016 19:26:53 UTC+2, Rafał Wołoszyn wrote:

Hi all,

As far as I know Gerit uses its own Git repository, is it possible to use Gerrit only as review tool with external repository ? 

Best regards,

Rafal

[Gaurav Negi]

Use Rietveld for that.

Sent from my iPhone

--

[David Pursehouse]

On Fri, Jun 3, 2016 at 3:33 AM 'Jonathan Nieder' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Luca Milanesio wrote:

There is a way of using it on existing repos:

a) Use Gerrit as first-point of contact for push

b) Use Gerrit for code-review

c) Configure replication from Gerrit to existing repos

d) Keep on using the existing repos for pulls / fetch

See an example on how we do this with GitHub at:

https://www.youtube.com/watch?v=jeWTvDad6VM

Yep, I've seen this kind of workflow work well.

Gerrit wants to be the only user that writes to the branch it controls (although it can tolerate some pushes behind its back to the repository on the same machine). It is acting like a human maintainer, so to speak.

What if the existing repo is controlled by a completely separate project? you might ask. E.g. what if you want to use Gerrit to develop a patched Linux kernel (the Linux kernel open source project doesn't use gerrit)? I've seen two approaches:

 a. Replicate the existing repo to a machine running Gerrit. Using Gerrit for code review, but don't ever Submit --- instead, once the patch is in good shape, send it upstream and click Abandon in Gerrit.

Or leave it open. Assuming you're regularly fetching and pushing updates from upstream into your Gerrit instance, and the Change-Id is in the commit message, Gerrit will automatically set the change to merged when it gets pushed in.

As a nice side-effect, any updates made to the patch upstream (for example the upstream maintainer might have rebased it) will be reflected as a new patch set on the change. Then you know that the change you see in Gerrit is what was actually merged.

Of course this doesn't work so well if the upstream maintainer removes the Change-Id lines.  Facebook does this with commits on buck, for example.

 

 b. Replicate refs/heads/master from the existing repo to refs/heads/upstream on a machine running Gerrit. Use Gerrit as usual to develop refs/heads/master. When you want to pull in the latest changes from upstream, run

  git fetch origin

  git checkout origin/master

  git pull origin upstream

  git push origin HEAD:refs/for/master 

This creates a change representing your intent to get the latest changes from upstream. The diff represent any changes you made to the automatic merge --- in other words, it says how you resolved conflicts --- so the diff will usually be empty. The change can be reviewed and submitted as usual to incorporate the latest upstream changes into master.

Hope that helps,

Jonathan

--

[Yaniv Levy]

Waking up an 8 year old thread. I'm in same position of this thread originator. I have pull and push permissions to an external git repository that receives contributions without a code review tools and this will remain this way.

I want my team's contributions to be reviewed and use Gerrit for that. I have the 'pull-replication' plugin pull into my Gerrit the external git 'master' branch. My review process is done in Gerrit up to the Merge position and then what? Abandon?.

Luca, correct me if I'm wrong, for stage e/f - I can't have Gerrit automatically merge into Gerrit master and push into the remote Git master branch. there will be conflicts because Gerrit is not the only one contributing to the external Git master branch. Is there a solution for that? or do I have to maintain a working git directories with two remotes (Gerrit, external Git ) and merge manually from <remote Gerrit> ref/changes/* to <remote external_git> master ?