Bug 61798 - GERRIT should show git:// URLs instead of https:// URLs by default (not logged in)
Summary: GERRIT should show git:// URLs instead of https:// URLs by default (not logge...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: WWW (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-04 15:40 UTC by Lionel Elie Mamane
Modified: 2015-02-19 16:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-03-04 15:40:32 UTC
When not logged in, gerrit should show, for the "checkout", "cherry-pick", etc command-lines examples using the smart/anonymous git:// protocol instead of the "dumb" https://.

So, e.g. instead of
 git pull https://gerrit.libreoffice.org/core refs/changes/08/2508/2
display
 git pull git://gerrit.libreoffice.org/core refs/changes/08/2508/2


It uses less bandwidth (when run on a repository that already has a "near" commit to the one being fetched), and avoids "errors" such as:
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://gerrit.libreoffice.org/core/info/refs
fatal: HTTP request failed

(Yes, I'm aware that I'm the "unusal" guy there, not having the StartCom root as trusted in my store.)
Comment 1 Joel Madero 2013-03-04 16:09:45 UTC
As it's you Lionel marking as NEW. 

Not sure who we ping about this or if you can take care of it
Comment 2 Lionel Elie Mamane 2013-03-04 17:28:30 UTC
Adding our gerrit experts (as per https://wiki.documentfoundation.org/FindTheExpert) to CC
Comment 3 Björn Michaelsen 2013-03-04 18:28:32 UTC
Hmm, I dont know. https:// should always work (as you are already viewing the webpage), while git might be eaten by a corp. firewall etc.. 

So I assume more people will have trouble with git: vs. https:
Comment 4 Lionel Elie Mamane 2013-03-04 18:46:16 UTC
(In reply to comment #3)
> Hmm, I dont know. https:// should always work (as you are already viewing
> the webpage), while git might be eaten by a corp. firewall etc.. 

Corporate firewall: good point.

How about putting a choice? When one is logged in, one has choice between "Anonymous HTTP", "SSH" or "HTTP". How about *adding* a choice of "Anonymous git", that both logged in and non-logged in users get?

Actually, the "Anonymous HTTP" and "HTTP" choices seem not to work at all.

I did:

$ export GIT_SSL_NO_VERIFY=true
$ git fetch https://lmamane@gerrit.libreoffice.org/core refs/changes/08/2508/4
## this was copy-pasted from https://gerrit.libreoffice.org/2508/

and I get:

fatal: Couldn't find remote ref refs/changes/08/2508/4
Unexpected end of command stream
Comment 5 DavidO 2013-03-04 20:10:17 UTC
> $ export GIT_SSL_NO_VERIFY=true
> $ git fetch https://lmamane@gerrit.libreoffice.org/core
> refs/changes/08/2508/4
> ## this was copy-pasted from https://gerrit.libreoffice.org/2508/
> 
> and I get:
> 
> fatal: Couldn't find remote ref refs/changes/08/2508/4
> Unexpected end of command stream

That's because you can only fetch a change that is active.
How about to try to fetch a change that has not been yet merged?

[david@wizball libo (master)] git fetch https://davido@gerrit.libreoffice.org/core refs/changes/49/2549/1 && git checkout FETCH_HEAD
From https://gerrit.libreoffice.org/core
 * branch            refs/changes/49/2549/1 -> FETCH_HEAD
M	translations
Note: checking out 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 6bb905f... Add PDF Mimetype to Draw
[david@wizball libo ((6bb905f...))]$ git checkout -b mimetype
M	translations
Switched to a new branch 'mimetype'
Comment 6 QA Administrators 2015-02-19 15:43:38 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
This NEW Message was generated on: 2015-02-19
Comment 7 DavidO 2015-02-19 15:58:48 UTC
Not our bug. Issue tracker for Gerrit Code Review is here: [1].

[1] https://code.google.com/p/gerrit/issues/list
Comment 8 Lionel Elie Mamane 2015-02-19 16:42:10 UTC
I'm fairly sure it is a question of configuration of the gerrit instance... not fixing the gerrit code. Anyway, is fixed now on our current gerrit instance.