git/gitweb, branch gitk-resize-error

Merge branch 'gh/gitweb-branch-sort'

2021-09-10T18:46:32Z

Tie-break branches that point at the same object in the list of branches on GitWeb to show the one pointed at by HEAD early. * gh/gitweb-branch-sort: gitweb: use HEAD as secondary sort key in git_get_heads_list()

gitweb: use HEAD as secondary sort key in git_get_heads_list()

2021-06-10T00:49:20Z

The "heads" section on the gitweb summary page shows heads in `-committerdate` order (ie. the most recently-modified ones at the top), tie-breaking equal-dated refs using the implicit `refname` sort fallback. This recency-based ordering appears in multiple places in the UI, such as the project listing, the tags list, and even the shortlog and log views. Given two equal-dated refs, however, sorting the `HEAD` ref before the non-`HEAD` ref provides more useful signal than merely sorting by refname. For example, say we had "master" and "trunk" both pointing at the same commit but "trunk" was `HEAD`, sorting "trunk" first helps communicate its special status as the default branch that you'll check out if you clone the repo. Add `-HEAD` as a secondary sort key to the `git for-each-ref` call in `git_get_heads_list()` to provide the desired behavior. The most recently committed refs will appear first, but `HEAD`-ness will be used as a tie-breaker. Note that `refname` is the implicit fallback sort key, which means that two same-dated non-`HEAD` refs will continue to be sorted in lexicographical order, as they are today. Signed-off-by: Greg Hurrell Signed-off-by: Junio C Hamano

gitweb: add "e-mail privacy" feature to redact e-mail addresses

2021-04-08T22:54:26Z

Gitweb extracts content from the Git log and makes it accessible over HTTP. As a result, e-mail addresses found in commits are exposed to web crawlers and they may not respect robots.txt. This can result in unsolicited messages. Introduce an 'email-privacy' feature which redacts e-mail addresses from the generated HTML content. Specifically, obscure addresses retrieved from the the author/committer and comment sections of the Git log. The feature is off by default. This feature does not prevent someone from downloading the unredacted commit log, e.g., by cloning the repository, and extracting information from it. It aims to hinder the low- effort, bulk collection of e-mail addresses by web crawlers. Signed-off-by: Georgios Kontaxis Acked-by: Eric Wong Acked-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

gitweb/Makefile: conditionally include ../GIT-VERSION-FILE

2020-12-09T00:56:56Z

The 'clean' target is still noticeably slow on cygwin, despite the improvements made by previous patches. For example, the second invocation of 'make clean' below: $ make clean >/dev/null 2>&1 $ make clean ... make[1]: Entering directory '/home/ramsay/git/gitweb' make[2]: Entering directory '/home/ramsay/git' make[2]: 'GIT-VERSION-FILE' is up to date. make[2]: Leaving directory '/home/ramsay/git' ... $ has been timed at 10.361s on my laptop (an old core i5-4200M @ 2.50GHz, 8GB RAM, 1TB HDD). Notice that the 'clean' target is making a nested call to the parent Makefile to ensure that the GIT-VERSION-FILE is up-to-date. This is to ensure that the $(GIT_VERSION) make variable is set, once that file had been included. However, the 'clean' target does not use the $(GIT_VERSION) variable, directly or indirectly, so it does not have any affect on what the target removes. Therefore, the time spent on ensuring an up to date GIT-VERSION-FILE is wasted effort. In order to eliminate such wasted effort, use the value of the internal $(MAKECMDGOALS) variable to only '-include ../GIT-VERSION-FILE' when the target is not 'clean'. (This drops the time down to 8.430s, on my laptop, giving an improvement of 18.64%). Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

Merge branch 'eb/gitweb-more-trailers'

2020-05-01T20:39:56Z

Gitweb updates. * eb/gitweb-more-trailers: gitweb: Recognize *-to and Closes/Fixes trailers

gitweb: Recognize *-to and Closes/Fixes trailers

2020-04-25T05:19:04Z

Commit trailers like "Thanks-to:", "Fixes:", and "Closes:" are fairly common, but gitweb didn't highlight them like other trailers. Signed-off-by: Emma Brooks Signed-off-by: Junio C Hamano

gitweb: fix UTF-8 encoding when using CGI::Fast

2020-03-29T16:06:51Z

FCGI streams are implemented using the older stream API: TIEHANDLE, therefore applying PerlIO layers using binmode() has no effect to them. The solution in this patch is to redefine the FCGI::Stream::PRINT function to use UTF-8 as output encoding, except within git_blob_plain() and git_snapshot() which must still output in raw binary mode. This problem and solution were previously reported back in 2012: - http://git.661346.n2.nabble.com/Gitweb-running-as-FCGI-does-not-print-its-output-in-UTF-8-td7573415.html - http://stackoverflow.com/questions/5005104 Signed-off-by: Julien Moutinho Signed-off-by: Junio C Hamano

Merge branch 'do/gitweb-typofix-in-comments'

2020-01-08T20:44:11Z

Typofix. * do/gitweb-typofix-in-comments: gitweb: fix a couple spelling errors in comments

gitweb: fix a couple spelling errors in comments

2020-01-04T23:09:33Z

Signed-off-by: Denis Ovsienko Signed-off-by: Junio C Hamano

Merge branch 'jk/gitweb-anti-xss'

2019-12-01T17:04:41Z

Some codepaths in "gitweb" that forgot to escape URLs generated based on end-user input have been corrected. * jk/gitweb-anti-xss: gitweb: escape URLs generated by href() t/gitweb-lib.sh: set $REQUEST_URI t/gitweb-lib.sh: drop confusing quotes t9502: pass along all arguments in xss helper