| Issue 1351: | Git push support to remote master repository | |
| 31 people starred this issue and may be notified of changes. | Back to list |
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.
Apr 23, 2012
#1
sop@google.com
Labels:
-Type-Bug Type-Feature
Apr 24, 2012
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.
Apr 24, 2012
> 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.
Status:
Accepted
Nov 20, 2012
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.
Feb 7, 2013
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
Mar 7, 2013
any progress on this?
May 3, 2013
+tajj.shakil@gmail.com
Aug 30, 2013
This is very relevant to this issue: http://issues.tmatesoft.com/issue/SGT-632 |
|
| ► Sign in to add a comment |