Community
Participate
Working Groups
On CDT we (again?) had an accidental push to refs/for/master in git instead of gerrit. Would it be possible to add a server side hook, perhaps as Matthias has suggested in Bug 491464 (which covers the client side of the change)? (In reply to Matthias Sohn from Bug 491464 comment #1) > I think this should be prevented on server side by installing a pre-receive > hook, > this way also pushes from other git implementations to this magic ref will > be rejected > > Contact webmaster@eclipse.org if you want this for a git repository hosted > at Eclipse > > the hook may look like (completely untested): > > #! /bin/sh > # reject push to Gerrit magic refs "refs/for/<branch name>" which is not > # understood by plain git > while read old new longref; do > case $longref in > refs/for/*) > echo "push to $longref rejected > You pushed to a plain bare git repository using a Gerrit magic ref > which isn't supported by plain git > Push to https://git.eclipse.org/r if you want to use Gerrit Code > Review at Eclipse" > exit 1 > esac > done > > for details about pre-receive hooks see section "pre-receive" in [1] > > [1] https://git-scm.com/docs/githooks
Let's just change the file permissions to prevent direct SSH access and use Gerrit for everyting. This does not mean code review for everything -- push to refs/heads/master goes into HEAD directly, push to refs/for/master triggers review.
(In reply to Denis Roy from comment #1) > Let's just change the file permissions to prevent direct SSH access and use > Gerrit for everyting. This does not mean code review for everything -- push > to refs/heads/master goes into HEAD directly, push to refs/for/master > triggers review. From me there is no objection to that, there was a longish conversation on cdt-dev (that led to this bug report) [1]. I don't know enough about Eclipse processes on making such decisions, so I leave that in your hands. Thanks Denis! [1] https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30546.html
cc'ing the project leads for +1 on the permissions change: (In reply to Denis Roy from comment #1) > Let's just change the file permissions to prevent direct SSH access and use > Gerrit for everyting. This does not mean code review for everything -- push > to refs/heads/master goes into HEAD directly, push to refs/for/master > triggers review.
(In reply to Denis Roy from comment #3) > cc'ing the project leads for +1 on the permissions change: This is ok for me but I'll let Doug make the final call as he may like the flexibility of having that option.
(In reply to Marc Khouzam from comment #4) > (In reply to Denis Roy from comment #3) > > cc'ing the project leads for +1 on the permissions change: > > This is ok for me but I'll let Doug make the final call as he may like the > flexibility of having that option. I fear not having it but I'll vote 0 since not having it probably doesn't matter that much. I haven't used it in a long time.
(In reply to Doug Schaefer from comment #5) > (In reply to Marc Khouzam from comment #4) > > (In reply to Denis Roy from comment #3) > > > cc'ing the project leads for +1 on the permissions change: > > > > This is ok for me but I'll let Doug make the final call as he may like the > > flexibility of having that option. > > I fear not having it but I'll vote 0 since not having it probably doesn't > matter that much. I haven't used it in a long time. Ok, so let's try it. I will warn our committers that this will be happening. It will be their final warning to move to the Gerrit URL.
I've renamed the bug to match what will be done. As a note, Jonah had brought up the fact that the server hook could be done for all projects and therefore protect all projects. Are there many projects that have direct access and therefore have the risk of pushing real refs/for/* branches? or is it fine to just focus on CDT for this bug?
Which repo is this for? Or shall we just do it on all repos?
(In reply to Denis Roy from comment #8) > Which repo is this for? Or shall we just do it on all repos? Yes, please. Do all of them under gitroot/cdt. BTW, if I want to make a new repo, how do we do it and get the permissions correct? With our gerrit instance at BlackBerry, I can issue a create-project command over the 29418 port to do it. But I'm not sure how much Gerrit magic gets involved with that.
Gerrit repos are still created manually / webmaster stuff. I have plans for addressing that, but getting to it is challenging. For Gerrit we create a "permissions" project for each Eclipse project, then set that project as the parent of all your repos. ssh -p 29418 gerrit gerrit set-project-parent --parent permissions/cdt-dev cdt/org.eclipse.cdt.master All the CDT repos are under Gerrit control and all of them allow direct push to refs/heads/master. Please use the Gerrit URLs for all Git operations. Here is a list of the CDT projects -- clone URLs are within. https://git.eclipse.org/r/#/admin/projects/?filter=cdt (In reply to Jonah Graham from comment #0) > On CDT we (again?) had an accidental push to refs/for/master in git instead > of gerrit. Has the bad ref been cleared?
(In reply to Denis Roy from comment #10) > All the CDT repos are under Gerrit control and all of them allow direct push > to refs/heads/master. Please use the Gerrit URLs for all Git operations. I've notified committers via the mailing list that they must use the Gerrit URL. > (In reply to Jonah Graham from comment #0) > > On CDT we (again?) had an accidental push to refs/for/master in git instead > > of gerrit. > > Has the bad ref been cleared? Yes, that was fixed. Thanks for asking.
Great, I think we're done here.
Thanks Denis!
I'm no longer able to push using ssh://sprigogin@git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git with refs/heads/master. Wasn't the intention to disable push to refs/for/master only?
(In reply to Sergey Prigogin from comment #14) > I'm no longer able to push using > ssh://sprigogin@git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git with > refs/heads/master. Wasn't the intention to disable push to refs/for/master > only? Nope, that's not what was decided. But you should be able to push directly to refs/heads/master at ssh://sprigogin@git.eclipse.org:29418/cdt/org.eclipse.cdt.git without creating a change request.
Direct push to refs/heads/master at ssh://sprigogin@git.eclipse.org:29418/cdt/org.eclipse.cdt.git does work but in EGit it doesn't update local state and I have to pull explicitly to get rid of the outgoing change.
Please revert the change since it had unintended consequences described in comment #14 and comment #16.
(In reply to Sergey Prigogin from comment #17) > Please revert the change since it had unintended consequences described in > comment #14 and comment #16. What version of Egit are you using? I do regular direct pushes and don't see that problem. And 14 is negated by 15 :). I've been using Gerrit both at Eclipse and at QNX in this mode without issue for years.
(In reply to Doug Schaefer from comment #18) > (In reply to Sergey Prigogin from comment #17) > > Please revert the change since it had unintended consequences described in > > comment #14 and comment #16. > > What version of Egit are you using? I do regular direct pushes and don't see > that problem. And 14 is negated by 15 :). > > I've been using Gerrit both at Eclipse and at QNX in this mode without issue > for years. I'll take that back a bit. I used to see the issue you were having but that was with EGit in Luna.
(In reply to Doug Schaefer from comment #19) > (In reply to Doug Schaefer from comment #18) > > (In reply to Sergey Prigogin from comment #17) > > > Please revert the change since it had unintended consequences described in > > > comment #14 and comment #16. > > > > What version of Egit are you using? I do regular direct pushes and don't see > > that problem. And 14 is negated by 15 :). > > > > I've been using Gerrit both at Eclipse and at QNX in this mode without issue > > for years. > > I'll take that back a bit. I used to see the issue you were having but that > was with EGit in Luna. Also, just to make sure we're talking about the same thing. I push directly by selecting the branch and doing a "Push Branch". And the most recent EGit cleans up some of the UX around the "Commit and Push" button in the Staging view so you can us it with more confidence that you're actually pushing to refs/for or refs/draft and not direct.
(In reply to Doug Schaefer from comment #20) I'm using latest EGit nightly and pushing by clicking on Remote > Push... from the context menu of the git repository clone. The magic trick suggested by Matthias Sohn in http://eclip.se/491464#c1 promised "reject push to Gerrit magic refs "refs/for/<branch name>" which is not understood by plain git", but instead push to ssh://<username>@git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git was disabled completely.
> What version of Egit are you using? I do regular direct pushes and don't see > that problem. Agreed ... Could you take some screenshots of the push refs?
BTW, the plan as I understood it was to make this change anyway so we only have one way of managing git access to the repos, and to do it for all projects. Having the golden repo sitting on the file system open to everyone is quite scary. But at the end of the day, doesn't matter to me. I'm was working 100% against the Gerrit repo, including direct pushes, anyway so this change didn't affect me.
(In reply to Doug Schaefer from comment #23) Doug, what is you origin points to, Gerrit or Git? Mine points to Git because it was used for original cloning as recommended in https://wiki.eclipse.org/Getting_started_with_CDT_development
Created attachment 261165 [details] First page of the push wizard
Created attachment 261166 [details] Second page of the push wizard
Created attachment 261167 [details] Third page of the push wizard
Created attachment 261168 [details] Error message This and previous attachments illustrate that push to refs/heads/master using git URL doesn't work.
(In reply to Sergey Prigogin from comment #24) > (In reply to Doug Schaefer from comment #23) > > Doug, what is you origin points to, Gerrit or Git? Mine points to Git > because it was used for original cloning as recommended in > https://wiki.eclipse.org/Getting_started_with_CDT_development You can modify your 'origin' entry to replace the URL with the Gerrit URL. Then everything will work. You can make the change using EGit or command-line. I can provide pointers if needed. You don't need to have the direct fit URL at all anymore.
> You can modify your 'origin' entry to replace the URL with the Gerrit URL. > Then everything will work. You can make the change using EGit or > command-line. I can provide pointers if needed. > > You don't need to have the direct fit URL at all anymore. +1 /gitroot URIs are obsolete. (In reply to Doug Schaefer from comment #23) > BTW, the plan as I understood it was to make this change anyway so we only > have one way of managing git access to the repos, and to do it for all > projects. Having the golden repo sitting on the file system open to everyone > is quite scary. This is correct. At some point SSH access through the system SSh will be disabled, and all Git SSH access will be done through jSch.
https://wiki.eclipse.org/Getting_started_with_CDT_development has to be updated to reflect the new reality.
(In reply to Sergey Prigogin from comment #24) > (In reply to Doug Schaefer from comment #23) > > Doug, what is you origin points to, Gerrit or Git? Mine points to Git > because it was used for original cloning as recommended in > https://wiki.eclipse.org/Getting_started_with_CDT_development I made a new remote pointing at Gerrit and deleted the old one and the set up the branch properties to pull from the new remote.
Never mind. What Marc, said. (Sorry, was replying to them in order).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I think this is fully done.
