Git push support to remote master repository

[GoogleCodeExporter]

Gerrit cannot initiate a git push from its repository since the tool expects to 
interact directly with the master repository. If you run gerrit on another 
system and try to push to the for instance gitolite master the gerrit server 
will drift away when new commits are pushed to the gitolite master and cannot 
be pulled back into gerrit and merged with what gerrit has and pushed back.

For the moment, Gerrit does not really play nicely as a "user". Gerrit assumes 
it manages the team's main repository.

Meanwhile Gerrit can provide direct push access for a freshly established 
repository there are many gitolite customers out there with large developer 
base in which cases it would just be too intrusive to change the whole system 
from one day to another from gitolite to gerrit, if any. There would be a 
better and smoother transition, if the Gerrit experiment could be achieved as 
an "extra", and the developers who do not care about this service, they could 
still continue their daily workflow.

Gerrit and gitolite get along so long as they can share the same repository on 
disk and thus lock against each other with the standard git locking protocol. 
Provided they use the same user name under the Unix system. All in all, it 
would be nice to manage the situation that way, but there are places with 
security concerns where a webapplication like this cannot run on the same 
server where gitolite resides. No matter what, if it has been a sysadmin policy 
for many years, it is too intrusive to go against that, if there is a better 
solution.

"MergeOp would need to make the new commit it is submitting, but instead of 
updating the git repository, push that commit to the remote master and only 
update its local master if the remote master accepted it. If the remote master 
rejected due to non-fast-forward, fetch the remote master, update its local 
reference, and retry the merge and ReceiveCommits has to do the same thing for 
any direct push, or just deny doing direct pushes in gerrit when there is this 
remote master" - spearce.

Original issue reported on code.google.com by djsza...@gmail.com on 23 Apr 2012 at 11:08

[GoogleCodeExporter]

Original comment by sop@google.com on 23 Apr 2012 at 11:09

• Added labels: Type-Feature
• Removed labels: Type-Bug

[GoogleCodeExporter]

Just to indicate why this is essential: KDE has a large established 
infrastructure, containing 378 standard repositories, and numerous clone and 
scratch repositories on top of that. 

As such, we have a scripted setup which is tied quite heavily into Gitolite. We 
also have numerous server side commands which Gitolite provides which are 
essential to our workflow, especially concerning the setup process for 
repositories (the first push), as well as the management of scratch 
repositories.

Any developer can create a scratch repository at any time.

We also have a network of anonymous access git mirrors which themselves use 
scripts based on the output of Gitolite. Our current Git Hooks also depend upon 
the way Gitolite communicates with secondary update scripts in order to 
determine the person pushing the commit.

As such, simply wanting to merely test Gerrit as a code review tool seems to be 
a very hard ask, as it is not a code review tool but a git repository 
management tool - something we already have, and have built tools around.

I will note that Gerrit is only able to superficially meet the powers of 
Gitolite's access control system. Gitolite provides much, much more power (you 
cannot block individual branch names either by name or by regex with Gerrit - 
Gitolite can).

Further, KDE has a workflow where developers are able to push directly into any 
repository, including the scratch repositories of others.

Original comment by sourto...@gmail.com on 24 Apr 2012 at 9:27

[GoogleCodeExporter]

> I will note that Gerrit is only able to superficially meet the powers of
> Gitolite's access control system. Gitolite provides much, much more
> power (you cannot block individual branch names either by name or
> by regex with Gerrit - Gitolite can).

Uhm, really? Gerrit had all of the branch level access controls first. Gitolite 
implemented this stuff later and had to  do it in a hacky way using temporary 
repositories that had a subset of refs. I'm still not 100% certain how they 
implement the same level of branch access controls that Gerrit is capable of 
doing.

If I understand this remark I quoted correctly, you want to block users from 
creating or pushing to a branch of a certain naming pattern like 
refs/heads/.*(BAD|EVIL).*. You can do this in Gerrit by creating a reference 
section whose name is "^refs/heads/.*(BAD|EVIL).*" (the leading ^ means its a 
regex anchored at the start of the reference name), mark the entry exclusive. 
Nobody has access to names that match that pattern, unless there is a more 
specific pattern used elsewhere that overrides this pattern. E.g. 
"refs/heads/ITS.OK.TO.BE.EVIL" is more specific than the regex and can 
therefore override that entry that granted nobody access.

So I would be really interested in seeing a Gitolite ACL that can't be 
expressed in Gerrit.

Assuming Gerrit was running on the same host as the Gitolite repositories, 
Gerrit 2.2/2.3 should play nice by automatically registering a new repository 
as soon as it is created in the proper base directory. Access controls would be 
missing by default, but could be assigned later.

The idea of a scratch repository is a bit foreign to Gerrit. One of the 
motivations to making the tool was to have a central repository with all 
relevant reviews associated with that one repository. We wanted to avoid 
developers making their own private fork repositories and stashing their code 
there, because it reduced the chances that someone would find the code, review 
it, and decide it was worth including or not. Its a different workflow model.

Original comment by sop@google.com on 24 Apr 2012 at 2:15

• Changed state: Accepted

[GoogleCodeExporter]

We would like to introduce Gerrit in our team. We are just planning on 
migrating to git and for the time being, we will try to run SVN and git in 
parallel with something like Subgit to keep the two synced.

In order to also have Gerrit in the mix, we would like to be able to commit via 
Git to Gerrit and, after review, push changes to the remote repo, which is kept 
in sync with the SVN repo. Also, checkins via SVN, which are mirrored back by 
Subgit to the remote repo, should be visible in Gerrit, but without the review, 
as they have obviously already been accepted (or rather circumvented Gerrit).

So, having Gerrit work as a kind of optional gate keeper to a remote repo is a 
valid and important use case to us.

Original comment by wolfgang...@fluidops.com on 20 Nov 2012 at 1:39

[GoogleCodeExporter]

It looks like the code is half-way there. The ref-update (not ref-updated) hook 
introduced in commit f736d6cd9f7ffa8e1c20590d9f37ae3593e6f163 is (by design) 
invoked in a blocking mode and if it fails, the ref update is denied. 
Unfortunately, this hook is executed only when one performs a direct push to a 
branch, not when Gerrit itself "merges" the changes ("merge" as in "updates the 
ref", not as in "creates a merge commit").

If I'm correct, a proper fix is to patch the MergeOp.java to invoke this hook 
just prior to calling branchUpdate.update(rw) in the updateBranch method. I'll 
give it a try this weekend, hopefully.

And just to clarify, this will only work reasonably well when:

- people actually write a proper hook with something like `git push $something 
upstream || exit 1`
- nothing but an automated mirroring script triggered by the upstream repo can 
direct-push to gerrit

Original comment by j...@flaska.net on 7 Feb 2013 at 12:47

[GoogleCodeExporter]

any progress on this?

Original comment by alin.sim...@gmail.com on 7 Mar 2013 at 6:49

[GoogleCodeExporter]

+tajj.shakil@gmail.com

Original comment by Tajj.Sha...@gmail.com on 3 May 2013 at 5:05

[GoogleCodeExporter]

This is very relevant to this issue:
http://issues.tmatesoft.com/issue/SGT-632

Original comment by sr.magaf...@tensor.ru on 30 Aug 2013 at 10:40