delta/git.git/gitweb, branch ks/status-initial-commit

doc: use https links to Wikipedia to avoid http redirects

2017-05-15T04:04:54+00:00

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:46+00:00

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:55+00:00

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:51+00:00

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:31+00:00

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:11+00:00

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:03+00:00

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

gitweb: escape link body in format_ref_marker

2016-08-01T19:55:40+00:00

Fix a case where an html link can be generated from unescaped input
resulting in invalid strict xhtml or potentially injected code.

An overview of a repo with a tag "1.0.0&0.0.1" would previously result
in an unescaped ampersand in the link body.

Signed-off-by: Andreas Brauchli 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

Merge branch 'sk/gitweb-highlight-encoding' into HEAD

2016-05-18T21:40:10+00:00

Some multi-byte encoding can have a backslash byte as a later part
of one letter, which would confuse "highlight" filter used in
gitweb.

* sk/gitweb-highlight-encoding:
  gitweb: apply fallback encoding before highlight

gitweb: apply fallback encoding before highlight

2016-05-03T18:32:31+00:00

Some multi-byte character encodings (such as Shift_JIS and GBK) have
characters whose final bytes is an ASCII '\' (0x5c), and they
will be displayed as funny-characters even if $fallback_encoding is
correct.  This is because `highlight` command always expects UTF-8
encoded strings from STDIN.

    $ echo 'my $v = "申";' | highlight --syntax perl | w3m -T text/html -dump
    my $v = "申";

    $ echo 'my $v = "申";' | iconv -f UTF-8 -t Shift_JIS | highlight \
        --syntax perl | iconv -f Shift_JIS -t UTF-8 | w3m -T text/html -dump

    iconv: (stdin):9:135: cannot convert
    my $v = "

This patch prepare git blob objects to be encoded into UTF-8 before
highlighting in the manner of `to_utf8` subroutine.

Signed-off-by: Shin Kojima 
Reviewed-by: Jakub Narębski 
Signed-off-by: Junio C Hamano