Feature Request P2
Status Update
No update yet.
Comments
da...@gmail.com
Is the idea to add more integration between gerrit and gitiles (which is now a core plugin), or replace gitiles with some other core implementation?
As a side note: we also still support gitweb. Should that be retired at some point? We are maintaining some theming features that were predominantly used by the now removed GWT but are still used in the gitweb servlet.
[Monorail components: ESC]
As a side note: we also still support gitweb. Should that be retired at some point? We are maintaining some theming features that were predominantly used by the now removed GWT but are still used in the gitweb servlet.
[Monorail components: ESC]
br...@google.com
+1 to better support the user journey of "I want to browse the code of a repo". I have struggled with that myself a couple of times.
-1 to native code browsing support in core Gerrit. Gerrit is primarily a code review system. Code searching browsing is really important and deserves a separate app.
As long as gitiles is clearly the best code browsing app I am fine with stronger support of that. But ultimately I would hope that something even better emerges. So I think using a plugin rather than core is fine.
My recommendation for the ESC: Change this FR to focus on the user journey.
Concrete proposal for improving the user journey: Looking at [1] add either a "Browse" section below the "Download" section with a link to gitiles. Or add a "browse code" link next to the "view changes" link above "Download".
[1]https://gerrit-review.googlesource.com/admin/repos/gerrit
-1 to native code browsing support in core Gerrit. Gerrit is primarily a code review system. Code searching browsing is really important and deserves a separate app.
As long as gitiles is clearly the best code browsing app I am fine with stronger support of that. But ultimately I would hope that something even better emerges. So I think using a plugin rather than core is fine.
My recommendation for the ESC: Change this FR to focus on the user journey.
Concrete proposal for improving the user journey: Looking at [1] add either a "Browse" section below the "Download" section with a link to gitiles. Or add a "browse code" link next to the "view changes" link above "Download".
[1]
br...@google.com
This was discussed in the last ESC meeting: https://www.gerritcodereview.com/2019-10-01-esc-minutes.html
The consensus was that code browsing is a separate concern and should not be built into core.
I would suggest to re-use this issue for making the "I want to browse one of the repos" user journey easier. WDYT?
The consensus was that code browsing is a separate concern and should not be built into core.
I would suggest to re-use this issue for making the "I want to browse one of the repos" user journey easier. WDYT?
br...@google.com
[Monorail components: PolyGerrit]
br...@google.com
[Monorail components: -ESC]
zi...@gmail.com
+1 for easier way to browse repositories.
However, please do not neglect the other part of the feature request which I am copying here again:
As an additional benefit of having a native repository browser, it is then possible to create new change(s)
directly from browsing a repository/file. This is ideal for fixing small issues, like documentation, release notes,
typos, etc
However, please do not neglect the other part of the feature request which I am copying here again:
As an additional benefit of having a native repository browser, it is then possible to create new change(s)
directly from browsing a repository/file. This is ideal for fixing small issues, like documentation, release notes,
typos, etc
br...@google.com
I don't understand why the repository browser has to be native. The gitiles plugin or other code browsing solutions and use Gerrit's APIs to create small changes and link to them.
br...@google.com
Should we move this issue to the "gitiles" component and rename it to "Create a Gerrit change/edit from Gitiles"?
da...@gmail.com
SGTM
br...@google.com
[Monorail components: -PolyGerrit plugins>gitiles]
to...@chromium.org
> As an additional benefit of having a native repository browser, it is then possible to create new change(s)
directly from browsing a repository/file. This is ideal for fixing small issues, like documentation, release notes,
typos, etc...
I'm really interested in this, mainly for documentation. It seems relatively straightforward to add a button on pages rendered by gitiles that would call the necessary Gerrit APIs to do this (https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#create-change ). Should this new feature be a separate bug or keep it as part of this one?
directly from browsing a repository/file. This is ideal for fixing small issues, like documentation, release notes,
typos, etc...
I'm really interested in this, mainly for documentation. It seems relatively straightforward to add a button on pages rendered by gitiles that would call the necessary Gerrit APIs to do this (
is...@google.com
Edits were made to reflect the following in Monorail: auto-CCs.
ap...@google.com
Project: gitiles
Branch: master
commit 84fb315541de4364c63a55bda7b96a1a44e0637a
Author: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Date: Sat Nov 11 15:05:56 2023
Add link to file view for creating a Gerrit change/edit
Bug:
Change-Id: I726260840191f50eda9e1235bd2abd40eed11af8
M java/com/google/gitiles/BlobSoyData.java
M java/com/google/gitiles/PathServlet.java
M javatests/com/google/gitiles/PathServletTest.java
M resources/com/google/gitiles/templates/ObjectDetail.soy
https://gerrit-review.googlesource.com/392465
Branch: master
commit 84fb315541de4364c63a55bda7b96a1a44e0637a
Author: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Date: Sat Nov 11 15:05:56 2023
Add link to file view for creating a Gerrit change/edit
Bug:
Change-Id: I726260840191f50eda9e1235bd2abd40eed11af8
M java/com/google/gitiles/BlobSoyData.java
M java/com/google/gitiles/PathServlet.java
M javatests/com/google/gitiles/PathServletTest.java
M resources/com/google/gitiles/templates/ObjectDetail.soy
me...@mail.com
I consider this implemented now. Thanks to Sven and Nasser, could not have done it without you!
m....@gmail.com
I don't ever see batches plus when I click something I end up way off course. I stayed before I'm very new to all this and really need help
Description
This may be fine for a long term user of this Gerrit server. However, a new user would typically
like to first get familiar with the existing projects hosted on this Gerrit server.
For example the user typically wants to find the project he is interested in and then learn about
the project. Learning about the project is usually done by first reading the README.md,
then browsing the repository content to get a feeling about the (quality of the) code.
To do so the user must:
* click Browse > Repositories ...
* must know the repository name
* click on the repository name
* wonder what to do from that general project's page which provides a set of options which, a first time user,
typically cannot edit... and is not interested into it
* come to an idea to click the "branches" link...
* try clicking on the branch name: nothing happens, it is not a link
* figure out he has to click on a link named "(gitiles)" next to the branch he wants to browse (the user wonders
why did someone named that link "gitiles")?
* finally Gitiles repository browser opens.
* However, it is another world, another app. Gerrit menus are gone! The user is in another application.
Feature:
Finding a project and browsing the repository should be provided by the Gerrit UI
and should be a first class citizen in the Gerrit UI.
As an additional benefit of having a native repository browser, it is then possible to create new change(s)
directly from browsing a repository/file. This is ideal for fixing small issues, like documentation, release notes,
typos, etc...