What steps will reproduce the problem?
1. Go to https://chromium.googlesource.com/chromium/src.git for instance

What is the expected output? What do you see instead?
A RSS feed should be available.

What steps will reproduce the problem?
1. View github.googlesource.com


What is the expected output? What do you see instead?
I expect the repositories listed to be sorted lexicographically (AaBb-Az). Instead,
they are sorted A-Za-z.


Please provide any additional information below.

I'm not sure if the correct solution is:
DefaultAccess.java:102
    Map<String, RepositoryDescription> repos = Maps.newTreeMap(String.CASE_INSENSITIVE_ORDER);

or something more complicated using Collators to sort the package in a truly localized
way (to ensure that Foo and foo always sort the same way, rather than just normalizing
both to foo and having the comparator return 0).

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.

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.

works: https://gerrit.googlesource.com/gerrit/+log/stable-2.6..master
404: https://gerrit.googlesource.com/gerrit/+log/stable-2.6...master

I'd expect "+log/foo...bar" to give the same output as "git log foo...bar".

What steps will reproduce the problem?
1)Navigate to https://gwt.googlesource.com/gwt/+log/master/dev/core/src/com/google/gwt/dev/jjs/ast/CanHaveInitializer.java#

What is the expected output? What do you see instead?
Shows all commits to repo instead of only the three commits that affect that file (c133c9cce3b1756401eaf61b7446dbc84097aec6,a040454c50da5a930457cb01b0931823b1274f6b,9ddb1f155a36cd27c2ca57a31062d6b298f8cacb)

What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1.  Visit https://chromium.googlesource.com/chromium/src/+blame/master/content/renderer/render_view_impl.cc
2. On that page, click the "diff" link on the fifth line (https://chromium.googlesource.com/chromium/src/+/310ebd630b77e0f3883647ebcf7458b2010f0a51%5E%21/content/renderer/render_view_impl.cc)
3. On that page, click the parent "blame" link: https://chromium.googlesource.com/chromium/src/+blame/0c49552feeb890c8ea1f2f7f85bc249e9808a815/content/renderer/render_view_impl.cc

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

I'm not sure what I expected; I was exploring.  What I *got* was a 404, which I don't
think is intended.



What version of the product are you using? On what operating system?


Please provide any additional information below.

See subject.

Can be approximated with /+log/commit?format=JSON&n=1, but users want the list of changed
files as well.

What steps will reproduce the problem?
1. deploy application
2. apply fixes for issues 32 and 33
3. browse index page

What is the expected output? What do you see instead?
CSS fails to load (/gitiles/+static/gitiles.css not found)

What version of the product are you using? On what operating system?
commit 076b1bf9bb40bd653ff2642903c7efdd8bb36d32
x86_64-freebsd
Jetty 8.1.11

Please provide any additional information below.
No route is defined to have /+static/ served by the default servlet

I'd like to be able to query the git repository by SHA-1 of the object, without using
URL surgery. This is most useful in cut and paste situations.

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.

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.

You can probably base it off: http://hron.me/blog/2013/01/gitiles-install-howto/

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.

Gitiles has no INSTALL file (or documentation), therefore it is difficult for others
to build and run gitiles themselves.

It would be great if there was a doc that listed how gitiles URLs worked.
E.g.
- ?format=TEXT for base64-encoded file download
- ?n= and ?s= for log number/start offset
- the ultimate resolution to issue 26 (filter by author, others)
- other awesome gitiles features I don't even know about because they're not documented
:)

The current refs listing provided by +refs appears to be limited to refs/heads/ and
refs/tags/, and doesn't support JSON output. It would be useful to also be able to
list other refs/. Maybe +refs could default to the current listing, but could be extended
with an 'ls-remote'-style filter pattern as the path. If the JSON output could also
include the commit hash of each ref, like ls-remote, that would be perfect.

For instance, https://chromium.googlesource.com/external/msysgit/git/+refs only shows
the branches that we copy into refs/heads/ but there are actually a lot more branches
that are mirrored from upstream into refs/remotes/upstream/, so to get all upstream
branches:
https://chromium.googlesource.com/external/msysgit/git/+refs/remotes/upstream/*

or all 'master' branches (both refs/heads/ and refs/remotes/upstream/):
https://chromium.googlesource.com/external/msysgit/git/+refs/*/master

(FWIW, this is needed by some Chrome scripts which currently shell out to a local git
to run ls-remote, which prevents us from running those scripts on appengine.)

see https://gwt.googlesource.com/gwt/+blame/master/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
line 632

it references commit 782d732 and says it's 2 weeks old. but it's actually only a couple
of hours old at this moment.

it should be calculating off of the commit time, not the patch creation time.

ex.

https://chromium.googlesource.com/chromium/blink.git/+blame/87e70381aca484f1700ea23e72f5adc78dc4581c/Source/core/inspector/InspectorPageAgent.cpp

compared to

https://src.chromium.org/viewvc/blink/trunk/Source/core/inspector/InspectorPageAgent.cpp?annotate=172074

Line numbers are really important, this makes dealing with stack traces at specific
revisions very difficult.

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

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.

Look at https://eclipse.googlesource.com/jgit/jgit/+/00739e6f708465d43d7756e0a3ad5a699bf869cb

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

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.

What steps will reproduce the problem?
1. Add a note to a commit
2. Push the notes ref
3. View the commit with the note

What is the expected output? What do you see instead?
The note should be displayed after the commit message. It should also be exposed in
the JSON view. Currently, neither of these is done.

At the least, the note should show up when viewing a specific commit, e.g. 
https://<host>/<repo>/+/<hash>, since this is equivalent to 'git show <hash>'

Even better would be if the note also showed up in the /+log/ view JSON and pretty=full
view.

What steps will reproduce the problem?
1. Open https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/HEAD?s=7ff04292acca8ab38de5aa8e1bc4bef7a28a9d44
2. Try to understand when exactly a change was made

What is the expected output? What do you see instead?
Expected a popup tooltip with exact date and time on hovering the mouse.

-Support JSON/TEXT format for +log
-Support additional arguments similar to git log, e.g. filtering by author or date.

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.

[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.

What steps will reproduce the problem?
1. deploy application
2. browse first page


What is the expected output?
working index page

What do you see instead?
java.lang.NullPointerException: cfg


What version of the product are you using?
commit 076b1bf9bb40bd653ff2642903c7efdd8bb36d32

 On what operating system?
x86_64-freebsd

Please provide any additional information below.
com.google.gitiles.GitilesFilter.setDefaultFields fails to set this.config if it is
null.

What steps will reproduce the problem?
1. Create a bare repository called foo.git
2. Create a folder called foo
3. Create a bare repository called foo/mytest.git
4. In gitiles, see that foo/* is not displayed

What is the expected output? What do you see instead?
I expect to see foo/ and foo/mytest listed in the repository list
I see no foo/ or foo/mytest

What version of the product are you using? On what operating system?
06edb506e453f3cf3db75a7d91d3035adcc03290

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

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. 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?

The default for all git command line tools is to display timezone offsets whenever displaying
absolute times; this should remain the default in gitiles as well.

However, some users may prefer to omit timezones in the web UI, which makes comparing
lists of timestamps easier (e.g. in blame). Add a gitiles.config option to set the
global timezone of the server.

Ideally, we would offer JSON and TEXT links for every view for which there is JSON or
TEXT available. Doing this manually in the templates is easy enough but is surely the
sort of thing we would forget to do. It might be nice to have it happen automatically,
in which case we would need to teach BaseServlet implementations how to advertise which
formats they support.

When looking at a log of a particular file (say https://chromium.googlesource.com/chromium/src/+log/master/chrome/browser/chrome_browser_main.cc),
there should be a way to jump directly to what that particular file looked like at
any given version.

Something that I frequently do before looking at the blame for a given version is to
scan the list of changes that touch a file until I find something that is relevant
and then take it from there.

In fact, maybe I rely on that functionality from http://src.chromium.org/viewvc even
more than actual blame.

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.

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).

What steps will reproduce the problem?
1. deploy WAR file from gitiles build
2. note that a config file pointed to using com.google.gitiles.configPath is not found

What is the expected output?
Working index page

What do you see instead?
javax.servlet.ServletException: gitiles.baseGitUrl not set

What version of the product are you using?
commit 076b1bf9bb40bd653ff2642903c7efdd8bb36d32

On what operating system?
x86_64-freebsd

Please provide any additional information below.
web.xml in the packaged WAR sets a non-null value for init param configPath, so that
the property is never taken into account.

The JSON link at the bottom of  https://android.googlesource.com/ is not valid JSON

https://android.googlesource.com/?format=JSON

It starts with ")]}'" at the front of the file?  Maybe this is an attempt at JSONP
gone wrong?

View a diff e.g.:

https://android.googlesource.com/kernel/common/+/226ff5394a249a579b52d398e8aa1b5a9dcb8340%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.

1. Extract the content of gitiles-war-1.0-SNAPSHOT.war file to <tomcat_dir>/webapps/gitiles/
2. Edit <tomcat_dir>/webapps/gitiles/WEB-INF/web.xml, change param value of init param
"configPath" to the path of gitiles config file.
3. Start up tomcat, visit http://<server>:<port>/gitiles/

HTTP 500
javax.servlet.ServletException: gitiles.baseGitUrl not set
	com.google.gitiles.GitilesFilter.getBaseGitUrl(GitilesFilter.java:416)
	com.google.gitiles.GitilesFilter.setDefaultUrls(GitilesFilter.java:333)
	com.google.gitiles.GitilesFilter.setDefaultFields(GitilesFilter.java:301)
	com.google.gitiles.GitilesFilter.init(GitilesFilter.java:198)
	com.google.gitiles.GitilesServlet.init(GitilesServlet.java:73)
        ...


The problem is in com.google.gitiles.GitilesConfig

  public static File defaultFile(FilterConfig filterConfig) {
    String configPath = System.getProperty(PROPERTY_NAME, DEFAULT_PATH);    //configPath
will never be null
    if (configPath == null && filterConfig != null) {
      configPath = filterConfig.getInitParameter(FILTER_CONFIG_PARAM);      //this
line will never be reached
    }
    return new File(configPath);
  }

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.

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?

[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.)

Ye olde' chromium git repo could show changes by various fields: 
http://git.chromium.org/gitweb/?p=chromium/src.git;a=search_help

AFACIT gitiles (https://chromium.googlesource.com/chromium/chromium/+/trunk) has no
equivalent functionality. 
Could it be added?

in this page you can see two timestamps:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/2b6e489fb5bbab066c8dd55167dc40d790c91bab

but there's no information to indicate what timezones those are in.  the reasonable
thing would be to assume they're localized, but we have way too many bad systems at
Google that blindly output PST or are otherwise local to the system/office.  adding
the explicit timezone (or the UTC offset) would make the output unambiguous & reliable
all the time.  all other git viewers i've used include this.

issue 5 covered normalizing the timestamps from various sources to one timezone which
is fine, but the final timezone should not be stripped.  collapsing them in the blame
output so as to get more content in the output is easy to do, but that's still unrelated
to displaying the timestamp in the log output (as quoted above).

When posting gitiles file-view URL's into bug reports, it would be very nice to be able
to link to an html anchor for the exact line I'm interested in.  Something like:

https://gerrit.googlesource.com/gitiles/+/master/gitiles-war/src/main/webapp/WEB-INF/web.xml#line20

Ideally, the html might look like this:

<li class="L9"><a name="line20"><a href="#line20"><span>...</span></a></a><br></li>

The <a href="#line20"> is just to make it easy to right-click and "Copy link address"

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.

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.