royue / gitiles Goto Github PK

Handle an anchor tag in a file URL to jump to a line number like gitweb does by 
appending #l<number> to the blob.

Also annoying problem is that since the UI renders the file lines using <li>, 
the generated numbers are not searchable in a browser. So there is currently no 
way to jump to a particular line by its number.

See attached diagram.

This may work into more navigation for pages other than the repository index 
page, but for now we can deal with some more density here.

Dark green and dark red don't stand out enough from black. Tweak these colors.

Tags are currently sorted alphanumerically, so e.g. "1.10" sorts before "1.2". 
Instead, sort them by date (with appropriate caching so tag objects don't need 
to be re-parsed).

For publicly-available Gitiles sites, it would be cool to have a Google search 
box on every page, e.g. posting to:
https://www.google.com/search?q=XYZ&sitesearch=https://android.googlesource.com/
tools/repo/+/master/subcmds/

The URL should be configurable, including no URL to mean no search box, for 
sites that administrators know aren't indexed by Google (e.g. on an intranet).

It seems unlikely that we would implement full-text search within Gitiles, but 
this is a quick hack that would get some of the way there.

[Condensed from discussion on a different bug tracker.]

dborowitz:
> I don't think prettify.js supports [deep linking to line number fragments]

sop:
It doesn't, that is why we don't have this feature. I wanted to add it
but it wasn't easy, so I punted.  :-)

dborowitz:
> so we'd either need to add it upstream or switch our prettification engine. 
We might be able to hack in some <a> tags in the output we throw in the <pre>, 
but I don't know how that will interact with prettify.

sop:
Uhm, you should look at what project hosting does... and not do that.
They run prettify.js, and then run another JavaScript that
post-processes the pretty.js output in order to reformat the HTML to
get anchors at each line, and reformat the whole thing into a table.
Actually this is similar to what Gerrit Code Review does too, but I
think the way Gerrit does this is only slightly less hacky. We don't
rely on a timer polling the window to see when prettify.js is done,
and then run twice.

I was leaning towards switching to Jgments and doing the formatting at
the server side, but [our internal] build is broken.... Formatting on the 
server side
will also bloat the response side significantly, but its what all of
the cool kids do (GitHub, ...).

Someone pointed out another JavaScript based formatter recently, but
it doesn't look to be nearly as pluggable as prettify.js is. It only
applies on <pre> blocks already in the DOM like prettify, you can't
call it and steal its output the way Gerrit does.

Similar to how Gerrit formats a file side by side, allow viewing a modified 
text file in a side by side view.

Gerrit's method of rendering this in a 4 column table with each line being a 
new row is horrid and should be replicated. Critique and GitHub get this more 
right by rendering 4 divs in a 1 row table, enabling the user to select a 
contiguous section of source code from either side.

Support downloading a tar (or zip) archive of a revision, e.g. 
/+archive/revision.tar.gz or /+archive/revision.zip to download a tgz or a zip.

[Discussion condensed from another bug tracker.]

The permission container projects like All-Projects, or Kernel-Projects on 
android should be hidden by default from the host index. These aren't really 
interesting for someone looking at source code.

There are times that an admin wants to browse these, so we should still make 
them available, but maybe collapse them under an expand out toggle, or move 
them to a second page with a link shown at the bottom of the main project 
listing.

Possibilities:
-Hide repos where HEAD points to refs/meta/config
-Hide repos that contain only refs/meta/config
-Hide repos that contain no branches or tags
(All of these are straightforwardly implemented in DefaultAccess or other 
GitilesAccess implementation.)

> What steps will reproduce the problem?
1. git clone https://gerrit.googlesource.com/gitiles && cd gitiles
2. Run "mvn package jetty:run"
3. Visit http://127.0.0.1:8080 in a browser

> What is the expected output? What do you see instead?

The browser shows that Jetty hasn't correctly initialized the war file.

Running "mvn jetty:run" in the gitiles-war directory works (more).  The path to 
the defaultsDescriptor in the root pom.xml must be changed to remove the 
gitiles-war/ prefix.  It then complains about not being configured (baseUrl 
etc), but if you put in some stub values the app then starts up.

I still have a few problems though even after this (e.g. the /+static/ path is 
giving 404s); I'm not sure if this is because the workaround broke other 
things...

What's the right way to launch the war?

Look at 
https://eclipse.googlesource.com/jgit/jgit/+/00739e6f708465d43d7756e0a3ad5a699bf
869cb

A number of files were deleted. The paths are listed as /dev/null

org.eclipse.jgit.packaging/org.eclipse.jgit.feature/feature.xml[diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
/dev/null[Deleted - diff]
org.eclipse.jgit.packaging/org.eclipse.jgit.pgm.feature/feature.xml[diff]
org.eclipse.jgit.packaging/pom.xml[diff]
15 files changed

Annotate the lines of a file with the revision they came from using the blame 
algorithm.

JGit blame is not identical to git-core's blame algorithm. Its a close 
approximation, but there are some differences in how JGit tracks the scoreboard 
and what annotations it can find.

Use /+blame/revision/path as the URL.

Because annotation is slow, results might want to be cached, and the page might 
want to use AJAX to feed down hunks of blame as they are discovered by the 
algorithm. This would be like the incremental blame display visible in git 
gui's blame window.

View a diff e.g.:

https://android.googlesource.com/kernel/common/+/226ff5394a249a579b52d398e8aa1b5
a9dcb8340%5E%21/#F0

The display should include + on the start of added lines and - on the start of 
lines that are deleted. These seem to be missing and only color is used to 
indicate addition or deletion.

When viewing the history of a branch, e.g. .../+log/master gitiles should use 
JavaScript if the browser supports it to replace the "Next >>" link with more 
records before the scroll bar makes the "Next >>" link visible.

This makes the UI appear as though the entire history is available, when its 
actually just paginated in from the backend on demand as the user scrolls 
through it.

What steps will reproduce the problem?
1.curl -s https://gerrit.googlesource.com/?format=JSON | head

What is the expected output? 
-------------------------------------------------------------------
{
  "Public-Plugins": {
    "name": "Public-Plugins",
    "clone_url": "https://gerrit.googlesource.com/Public-Plugins",
    "description": "Parent project for plugins/*"
  },
  "Public-Projects": {
    "name": "Public-Projects",
    "clone_url": "https://gerrit.googlesource.com/Public-Projects",
-------------------------------------------------------------------


What do you see instead?
Notice the very first line:)]}'
-------------------------------------------------------------------
)]}'
{
  "Public-Plugins": {
    "name": "Public-Plugins",
    "clone_url": "https://gerrit.googlesource.com/Public-Plugins",
    "description": "Parent project for plugins/*"
  },
  "Public-Projects": {
    "name": "Public-Projects",
    "clone_url": "https://gerrit.googlesource.com/Public-Projects",
-------------------------------------------------------------------

What version of the product are you using? On what operating system?
The version of gitiles that powers https://gerrit.googlesource.com/ at the time 
of writting

It would be cool to have some more icon variation in the tree view. We don't 
want to inspect file contents, which could be very slow, but we could use a 
simple extension map like we do for file detection in prettify.js.

GET 
android.googlesource.com/platform/packages/apps/Launcher/+/1dd3a077a293bf3ac%20%
204e61e91dcc3dfc99487acd4/res/values/dimens.xml

org.eclipse.jgit.errors.RevisionSyntaxException:1dd3a077a293bf3ac  
4e61e91dcc3dfc99487acd4
    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:706)
    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:385)
    at com.google.gitiles.RevisionParser.parse(RevisionParser.java:171)
    at com.google.gitiles.ViewFilter.parse(ViewFilter.java:116)
    at com.google.gitiles.ViewFilter.doFilter(ViewFilter.java:79)
    at com.google.gitiles.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:32)
    at com.google.gitiles.ViewFilter.doFilter(ViewFilter.java:33)

If the revision syntax expression is wrong the client should be given an error 
page under a 4xx status code and not an HTTP 500. A malformed request parameter 
should not cause a 500.

Support downloading the contents of a single file "as is" from Gitiles, for 
example:

 https://android.googlesource.com/platform/manifest/+raw/master/default.xml

to get the raw XML rather than it wrapped inside of HTML.

This is a bit of a challenge because the server has cookies, and this is 
possibly unsafe user supplied data. Raw HTML or JavaScript could cause the 
user's session to be able to be hijacked.

Gerrit has a way to configure regexp-based rules to create links in commit 
messages (among others) based on patterns: 
http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.1/config-gerrit
.html#_a_id_commentlink_a_section_commentlink

If would be great if Gitiles had such capability too, so that we could have the 
same links in both Gerrit (on gwt-review.googlesource.com for instance) and 
Gitiles (at gwt.googlesource.com)

Even minimal support for linking to issues and other revisions, with hard-coded 
patterns, as is possible on Google Code Hosting, would be appreciated.

When trying to view the source on the source viewer, I usually ended up 
clicking the project, then the branch, then the head commit, then the the tree 
link....

Sounds like a lot of clicks.... instead, install tree-links and get the link 
next to the branch.

Someone internal at Google wrote a Chrome extension to hack the DOM to do this. 
We should natively do it in the source browser templates.

On https://eclipse.googlesource.com/jgit/jgit/ branches overflow the list 
because we have ancient stable branches that aren't really as relevant. 
stable-2.2 is more recent but is buried on the next page.

Tags meanwhile are sorted by tag time and recent tags show up near the top of 
the list.

I wonder if we shouldn't try to do something similar to sort branches?

Follow a single level directory tree down to its first subtree that has more 
than one child.

In this page:

 https://gerrit.googlesource.com/gerrit/+/master/gerrit-patch-jgit

clicking on "src/" should take me to:

 https://gerrit.googlesource.com/gerrit/+/master/gerrit-patch-jgit/src/main/java/org/eclipse/jgit/

and not the fairly useless:

 https://gerrit.googlesource.com/gerrit/+/master/gerrit-patch-jgit/src/


This is tricky because we don't want to inflate each subtree when looking at 
the parent just to find out if its got >1 child or not. If we have the src/ URL 
just redirect when it finds itself in this case, you can't view src/ by itself 
anymore in the breadcrumb trail. Maybe we could force it to *not* auto-dive by 
putting a special URL in the breadcrumb trail when we know the parent has only 
one child, and skip the redirect for src/ if the URL was actually src/. (the 
illegal trailing single dot meaning show self and disable auto-dive).

This feature is primarily useful for Java projects like Gerrit where the 
package structure is really deep and single foldery all the way down. Its less 
useful on things like the kernel that have a sane directory tree layout.