Gerrit as an intermediate repository
Kohsuke Kawaguchi
I'm trying to wrap my head around Gerrit, and got one question.
Say I want to run Gerrit for a small team that works on a remote
"central" repository that someone else owns (say a team inside a
company working on an external open-source project.)
I'd like to use Gerrit for commits that our team produces, so that we
can review changes by each other before we push them to the central
repository, but in the mean time, other committers of the central
repository are making changes to the central repository. The trick is
not to create reviews for the changes made by other committrs pushing
directly to the central repository.
How do I make Gerrit work in a situation like this?
I thought about running this entirely outside Gerrit. I can let Gerrit
own its own repository, and someone else can then fetch from both the
central and Gerrit, merge changes, and push the result to both places,
bypassing the review.
The problem with this is that the review can be verified and submitted
successfully, only to fail during this last sync phase with the
central (if the change conflicts with someone else's commit pushed
directly to the central.)
If there's a hook before a change is merged, then I could use that to
pull from the central into Gerrit, thereby substantially reduce the
chance of such conflict happening during the push. But I don't see
such a hook.
Is there any way to make this work by other means?
--
Kohsuke Kawaguchi
Luca Milanesio
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
R. Tyler Croy
On Sat, 24 Sep 2011, Luca Milanesio wrote:
> Hi Kohsuke,
> glad to see you're looking into Gerrit ;-)
>
> Gerrit doesn't force the people to necessarily use code-review: your internal team could start using code-review whilst the other could see the repo as a standard GIT repository and push normally.
> You could define as well some "fine-grained" permissions to allow your internal team to require code-review ONLY for some "critical" branches.
>
> The "external world" could then use a 3rd party "central" repository owned by somebody else; your Gerrit instance would then synch just the public branches from the "central" repository (two-way synch) whilst the branches under code-review will always stay in your Gerrit instance.
>
> For configuring Gerrit "mirror" replication:
> http://gerrit.googlecode.com/svn/documentation/2.1.5/config-replication.html
I think it's worth mentioning that Gerrit replication (in my experience, this
might be configurable) will perform the equivalent of a `git push -f` to the
replication destination repository.
The Gerrit-branches vs. non-Gerrit branches seems like a decent way around
this.
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Chatter: http://identi.ca/agentdero
http://twitter.com/agentdero
Kohsuke Kawaguchi
that to my problem.
First, I don't see any two-way sync support in Gerrit mirror support.
Tyler's response also seems to agree with this (and if it's doing
"push -f" then I certainly can't use that to push into the central
repository!)
That leaves me with syncing outside Gerrit and pushing the resulting
ref into Gerrit, bypassing the review, and to the central. As I was
trying to explain, the thing I don't like about it is that you are
discovering the merge conflict too late. It'd be a lot nicer if I can
make the review fail, instead of having this later sync fail.
I was hoping to either hear that "no, the current version doesn't fit
that use case very well, and yes, that hook would do it nicely", or
"the current version works very well with that use case and here's how
to do it." Maybe I failed to articulate the setup and the problem I
see in it?
2011/9/24 Luca Milanesio <luca.mi...@gmail.com>:
--
Kohsuke Kawaguchi
Luca Milanesio
The only way in this case to avoid a "manual reconciliation" (your synch outside Gerrit and then push the results back to Gerrit) would be a "pluggable" external Git repository for Gerrit.
(this feature doesn't exist, as Gerrit uses directly a local jGit repo)
Not sure a combination of "hooks" on both Gerrit and remote GIT repo site would suffice in this case: you would always have the risk to have conflicts during hooks execution (one side or the other) in case of simultaneous push on both repos.
It is an interesting use-case anyway, as people using an existing GIT repo (i.e. GitHub) would think about using Gerrit as well as "Code-Review" lifecycle around it.
(see some discussion around this: http://stackoverflow.com/questions/2451644/gerrit-with-github)
Luca.
Magnus Bäck
Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> I'm trying to wrap my head around Gerrit, and got one question.
>
> Say I want to run Gerrit for a small team that works on a remote
> "central" repository that someone else owns (say a team inside a
> company working on an external open-source project.)
>
> I'd like to use Gerrit for commits that our team produces, so that we
> can review changes by each other before we push them to the central
> repository, but in the mean time, other committers of the central
> repository are making changes to the central repository. The trick is
> not to create reviews for the changes made by other committrs pushing
> directly to the central repository.
>
> How do I make Gerrit work in a situation like this?
>
> I thought about running this entirely outside Gerrit. I can let Gerrit
> own its own repository, and someone else can then fetch from both the
> central and Gerrit, merge changes, and push the result to both places,
> bypassing the review.
>
> The problem with this is that the review can be verified and submitted
> successfully, only to fail during this last sync phase with the
> central (if the change conflicts with someone else's commit pushed
> directly to the central.)
Yes, this is pretty much unavoidable. Whether you use Gerrit or not
there's always a race condition when two or more people push to the same
place. If both users pull/rebase from commit A and then push their own
commits B and C, only one of them can win. The loser must update from
the commit that reached the destination branch first.
> If there's a hook before a change is merged, then I could use that to
> pull from the central into Gerrit, thereby substantially reduce the
> chance of such conflict happening during the push. But I don't see
> such a hook.
Indeed not. You can however periodically update the branch available to
Gerrit. If you do this, say, every five minutes you will in most cases
be able to push straight from Gerrit to the externally hosted git. If
your users are good citizens and rebase sufficiently often and there
aren't too many upstream changes this'll probably work out fine. There
*will* be conflicts, but in most cases they'll be taken care of by the
authors of the changes (when their changes fail to merge) and not by
whoever is responsible for pushing your local branch to the upstream.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
Magnus Bäck
"R. Tyler Croy" <ty...@monkeypox.org> wrote:
> I think it's worth mentioning that Gerrit replication (in my
> experience, this might be configurable) will perform the equivalent
> of a `git push -f` to the replication destination repository.
This is indeed configurable. The push refspec for each remote is
specified in replication.config. It defaults to
+refs/heads/*:refs/heads/*
where the plus sign as usual indicates that non fast-forward updates
will take place. If you want to use Gerrit's replication for purposes
other than mirroring you might want to change this, but otherwise I
don't think it makes sense. A mirror should be a mirror at all times,
even if someone performs a possibly stupid action like a non
fast-forward update on the master (plus, there are legitimate
workflows that involves such updates).
[...]
Kohsuke Kawaguchi
> Apologies for the misunderstanding, I see your point now.
Thank you!
> The only way in this case to avoid a "manual reconciliation" (your
> synch outside Gerrit and then push the results back to Gerrit) would be
> a "pluggable" external Git repository for Gerrit.
> (this feature doesn't exist, as Gerrit uses directly a local jGit repo)
>
> Not sure a combination of "hooks" on both Gerrit and remote GIT repo
> site would suffice in this case: you would always have the risk to have
> conflicts during hooks execution (one side or the other) in case of
> simultaneous push on both repos.
I see what you mean. I was thinking about a hook mainly because it
seemed like a small change to vastly reduce the conflict risk, but you
are right that if we can make the whole pull/merge/push cycle a part of
the submit phase, that'd really eliminate any chance of an issue.
> It is an interesting use-case anyway, as people using an existing GIT
> repo (i.e. GitHub) would think about using Gerrit as well as "Code-
> Review" lifecycle around it.
>
> (see some discussion around this: http://stackoverflow.com/questions/2451644/gerrit-with-github)
Thanks for the pointer.
--
Kohsuke Kawaguchi http://kohsuke.org/