git/gitweb/gitweb.perl, branch v2.14.3

Merge branch 'hb/gitweb-project-list' into maint

2017-08-23T21:33:44Z

When a directory is not readable, "gitweb" fails to build the project list. Work this around by skipping such a directory. It might end up hiding a problem under the rug and a better solution might be to loudly complain to the administrator pointing out the problematic directory, but this will at least make it "work". * hb/gitweb-project-list: gitweb: skip unreadable subdirectories

gitweb: skip unreadable subdirectories

2017-07-18T19:10:17Z

gitweb terminates and shows no project list, if it can not access a sub-directory in the project root directory while looking for projects to show. Work it around by skipping unreadable directories. Signed-off-by: Hielke Christian Braun Signed-off-by: Junio C Hamano

Spelling fixes

2017-06-27T17:35:49Z

Signed-off-by: Ville Skyttä Signed-off-by: Junio C Hamano

doc: use https links to Wikipedia to avoid http redirects

2017-05-15T04:04:54Z

Signed-off-by: Sven Strickroth Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ab/gitweb-abbrev-links'

2016-10-26T20:14:46Z

In addition to purely abbreviated commit object names, "gitweb" learned to turn "git describe" output (e.g. v2.9.3-599-g2376d31787) into clickable links in its output. * ab/gitweb-abbrev-links: gitweb: link to "git describe"'d commits in log messages gitweb: link to 7-char+ SHA-1s, not only 8-char+ gitweb: fix a typo in a comment

gitweb: link to "git describe"'d commits in log messages

2016-10-14T20:22:55Z

Change the log formatting function to know about "git describe" output such as "v2.8.0-4-g867ad08", in addition to just plain "867ad08". There are still many valid refnames that we don't link to e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to v2.8.0-4-g867ad08, but I'm not supporting that with this commit, similarly it's trivially possible to create some refnames like "æ/var-gf6727b0" or which won't be picked up by this regex. There's surely room for improvement here, but I just wanted to address the very common case of sticking "git describe" output into commit messages without trying to link to all possible refnames, that's going to be a rather futile exercise given that this is free text, and it would be prohibitively expensive to look up whether the references in question exist in our repository. There was on-list discussion about how we could do better than this patch. Junio suggested to update parse_commits() to call a new "gitweb--helper" command which would pass each of the revision candidates through "rev-parse --verify --quiet". That would cut down on our false positives (e.g. we'll link to "deadbeef"), and also allow us to be more aggressive in selecting candidate revisions. That may be too expensive to work in practice, or it may not. Investigating that would be a good follow-up to this patch. Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano

gitweb: link to 7-char+ SHA-1s, not only 8-char+

2016-10-14T20:22:51Z

Change the minimum length of an abbreviated object identifier in the commit message gitweb tries to turn into link from 8 hexchars to 7. This arbitrary minimum length of 8 was introduced in bfe2191 ("gitweb: SHA-1 in commit log message links to "object" view", 2006-12-10), but the default abbreviation length is 7, and has been for a long time. It's still possible to reference SHA-1s down to 4 characters in length, see v1.7.4-1-gdce9648's MINIMUM_ABBREV, but I can't see how to make git actually produce that, so I doubt anyone is putting that into log messages in practice, but people definitely do put 7 character SHA-1s into log messages. I think it's fairly dubious to link to things matching [0-9a-fA-F] here as opposed to just [0-9a-f], that dates back to the initial version of gitweb from 161332a ("first working version", 2005-08-07). Git will accept all-caps SHA-1s, but didn't ever produce them as far as I can tell. Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano

gitweb: fix a typo in a comment

2016-10-14T20:22:31Z

Change a typo'd MIME type in a comment. The Content-Type is application/xhtml+xml, not application/xhtm+xml. Fixes up code originally added in 53c4031 ("gitweb: Strip non-printable characters from syntax highlighter output", 2011-09-16). Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano

gitweb: use highlight's shebang detection

2016-09-25T23:39:11Z

The "highlight" binary can, in some cases, determine the language type by the means of file contents, for example the shebang in the first line for some scripting languages. Make use of this autodetection for files which syntax is not known by gitweb. In that case, pass the blob contents to "highlight --force"; the parameter is needed to make it always generate HTML output (which includes HTML-escaping). Although we now run highlight on files which do not end up highlighted, performance is virtually unaffected because when we call highlight, it is used for escaping HTML. In the case that highlight is used, gitweb calls sanitize() instead of esc_html(), and the latter is significantly slower (it does more, being roughly a superset of sanitize()). Simple benchmark comparing performance of 'blob' view of files without syntax highlighting in gitweb before and after this change indicates ±1% difference in request time for all file types. Benchmark was performed on local instance on Debian, using Apache/2.4.23 web server and CGI. Document the feature and improve syntax highlight documentation, add test to ensure gitweb doesn't crash when language detection is used. Signed-off-by: Ian Kelling Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano

gitweb: remove unused guess_file_syntax() parameter

2016-09-25T23:39:03Z

Signed-off-by: Ian Kelling Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano