Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/gitweb
AgeCommit message (Collapse)Author
2023-12-19Merge branch 'js/update-urls-in-doc-and-comment'Junio C Hamano
Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. * js/update-urls-in-doc-and-comment: doc: refer to internet archive doc: update links for andre-simon.de doc: switch links to https doc: update links to current pages
2023-11-26doc: refer to internet archiveJosh Soref
These pages are no longer reachable from their original locations, which makes things difficult for readers. Instead, switch to linking to the Internet Archive for the content. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-26doc: update links for andre-simon.deJosh Soref
Beyond the fact that it's somewhat traditional to respect sites' self-identification, it's helpful for links to point to the things that people expect them to reference. Here that means linking to specific pages instead of a domain. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-26doc: switch links to httpsJosh Soref
These sites offer https versions of their content. Using the https versions provides some protection for users. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-26doc: update links to current pagesJosh Soref
It's somewhat traditional to respect sites' self-identification. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-17perl: bump the required Perl version to 5.8.1 from 5.8.0Todd Zullinger
The following commit will make use of a Getopt::Long feature which is only present in Perl >= 5.8.1. Document that as the minimum version we support. Many of our Perl scripts will continue to run with 5.8.0 but this change allows us to adjust them as needed without breaking any promises to our users. The Perl requirement was last changed in d48b284183 (perl: bump the required Perl version to 5.8 from 5.6.[21], 2010-09-24). At that time, 5.8.0 was 8 years old. It is now over 21 years old. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-06Merge branch 'jr/gitweb-title-shortening'Junio C Hamano
Gitweb had legacy URL shortener that is specific to the way projects hosted on kernel.org used to (but no longer) work, which has been removed. * jr/gitweb-title-shortening: gitweb: remove title shortening heuristics
2022-07-27gitweb: remove title shortening heuristicsJulien Rouhaud
Those heuristics are way outdated and too specific to the kernel project to be useful outside of kernel.org. Since kernel.org doesn't use gitweb anymore and at least one project complained about incorrect behavior, entirely remove them. Signed-off-by: Julien Rouhaud <julien.rouhaud@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-18Merge branch 'ab/build-gitweb'Junio C Hamano
Teach "make all" to build gitweb as well. * ab/build-gitweb: gitweb/Makefile: add a "NO_GITWEB" parameter Makefile: build 'gitweb' in the default target gitweb/Makefile: include in top-level Makefile gitweb: remove "test" and "test-installed" targets gitweb/Makefile: prepare to merge into top-level Makefile gitweb/Makefile: clear up and de-duplicate the gitweb.{css,js} vars gitweb/Makefile: add a $(GITWEB_ALL) variable gitweb/Makefile: define all .PHONY prerequisites inline
2022-06-28gitweb/Makefile: add a "NO_GITWEB" parameterÆvar Arnfjörð Bjarmason
From looking at the {Free,Net,Dragonfly}BSD packages for git[1] they've been monkeypatching "gitweb" out of the Makefile, let's be nicer and provide a NO_GITWEB=Y for their use. For the "all" target this allows for optionally restoring what's been the status quo before the preceding commit, but now we'll also behave correctly on the subsequent "make install". As before our installation of gitweb can be suppressed with NO_PERL. For backwards compatibility the NO_PERL=Y flag by itself still doesn't change whether or not we build gitweb, unlike the new NO_GITWEB=Y flag. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb/Makefile: include in top-level MakefileÆvar Arnfjörð Bjarmason
Include the gitweb/Makefile in the top-level Makefile rather than calling it as a sub-Makefile. As noted in the thread starting at at [1] (in particular [2]) we'll pay a high cost on NOOP runs of "make" just to figure out that we have nothing to do for "make gitweb". The "gitweb" script also isn't maintained out-of-tree, unlike "gitk-git" or "git-gui", which both have their own "Makefile". Other parts of it are already integrated into our main Makefiles, e.g. the documentation is built by Documentation/Makefile since 07ea4df2780 (gitweb: Add gitweb(1) manpage for gitweb itself, 2011-10-16). 1. https://lore.kernel.org/git/20220525205651.825669-1-szeder.dev@gmail.com/ 2. https://lore.kernel.org/git/220526.86k0a96sv2.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb: remove "test" and "test-installed" targetsÆvar Arnfjörð Bjarmason
Remove the special "test" targets for gitweb added in 958a8467216 (gitweb/Makefile: Add 'test' and 'test-installed' targets, 2010-09-26). Unlike e.g. "contrib/scalar" and "contrib/subtree" the "gitweb" tests themselves live in our top-level t/ directory. It therefore doesn't make sense to maintain this indirection, no more than it would to have a "git-send-email-test". By dropping it we'll also free other tests to use the t95*.sh prefix. These removed targets are unlikely to be used by anyone, and to the extent that they are we can easily use an invocation like this instead: make test T='t[0-9]*gitweb*.sh' Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb/Makefile: prepare to merge into top-level MakefileÆvar Arnfjörð Bjarmason
Since the "gitweb/Makefile" was split out from the top-level Makefile in 62331ef1637 (gitweb: Makefile improvements, 2010-01-30) we've kept the inter-dependencies between the two, and worse have dealt with a lot of duplication as a result. In preparation for merging the two again add a MAK_DIR_GITWEB variable to various rules in it. This will allow us to set this variable to "gitweb/" as we include it in the top-level Makefile, which will minimize the size of the subsequent diff. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb/Makefile: clear up and de-duplicate the gitweb.{css,js} varsÆvar Arnfjörð Bjarmason
Change the variable definitions for the $(GITWEB_CSS) and $(GITWEB_JS) so that we have a clear separation between what we use as "in" files, v.s. our "min" files. We can now make the appending to $(GITWEB_FILES) unconditional, since $(GITWEB_{JS,CSS}) is either the "min" or non-"min" version. This reduces the duplication within the file. While we're at it let's initialize "GITWEB_JSLIB_FILES" as we normally do with such variables. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb/Makefile: add a $(GITWEB_ALL) variableÆvar Arnfjörð Bjarmason
Declare the targets that the "all" target depends on with a new $(GITWEB_ALL) variable. This will help to reduce churn in subsequent commits. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-28gitweb/Makefile: define all .PHONY prerequisites inlineÆvar Arnfjörð Bjarmason
Move the '.PHONY' definition so that it's split up and accompanies the relevant as they're defined. This will make a subsequent diff smaller as we'll remove some of these, and won't need to re-edit the now-removed '.PHONY' line. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-02gitweb: switch to an XHTML5 DOCTYPEJason Yundt
According to the HTML Standard FAQ: “What is the DOCTYPE for modern HTML documents? In text/html documents: <!DOCTYPE html> In documents delivered with an XML media type: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML.” Source: [1] Gitweb uses an XHTML 1.0 DOCTYPE: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> While that DOCTYPE is still valid [2], it has several disadvantages: 1. It’s misleading. If an XML parser uses the DTD at the given link, then the entities &nbsp; and &sdot; won’t get declared. Instead, the parser has to use a DTD from the HTML Standard that has nothing to do with XHTML 1.0 [2]. 2. It’s obsolete. XHTML 1.0 was last revised in 2002 and was superseded in 2018 [3]. 3. It’s unreliable. Gitweb uses &nbsp; and &sdot; but lets an external file define them. “[…U]using entity references for characters in XML documents is unsafe if they are defined in an external file (except for &lt;, &gt;, &amp;, &quot;, and &apos;).” [4] [1]: <https://github.com/whatwg/html/blob/main/FAQ.md#what-is-the-doctype-for-modern-html-documents> [2]: <https://html.spec.whatwg.org/multipage/xhtml.html#parsing-xhtml-documents> [3]: <https://www.w3.org/TR/xhtml1/#xhtml> [4]: <https://html.spec.whatwg.org/multipage/xhtml.html#writing-xhtml-documents> Signed-off-by: Jason Yundt <jason@jasonyundt.email> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-08gitweb: remove invalid http-equiv="content-type"Jason Yundt
Before this change, gitweb would generate pages which included: <meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8"/> When a meta's http-equiv equals "content-type", the http-equiv is said to be in the "Encoding declaration state". According to the HTML Standard, The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents. Source: <https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-type> This change removes that meta element since gitweb always generates XML documents. Signed-off-by: Jason Yundt <jason@jasonyundt.email> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10Merge branch 'gh/gitweb-branch-sort'Junio C Hamano
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()
2021-06-10gitweb: use HEAD as secondary sort key in git_get_heads_list()Greg Hurrell
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 <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-09gitweb: add "e-mail privacy" feature to redact e-mail addressesGeorgios Kontaxis
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 <geko1702+commits@99rst.org> Acked-by: Eric Wong <e@80x24.org> Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-09gitweb/Makefile: conditionally include ../GIT-VERSION-FILERamsay Jones
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 <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-01Merge branch 'eb/gitweb-more-trailers'Junio C Hamano
Gitweb updates. * eb/gitweb-more-trailers: gitweb: Recognize *-to and Closes/Fixes trailers
2020-04-25gitweb: Recognize *-to and Closes/Fixes trailersEmma Brooks
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 <me@pluvano.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-29gitweb: fix UTF-8 encoding when using CGI::FastJulien Moutinho
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 <julm+git@sourcephile.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08Merge branch 'do/gitweb-typofix-in-comments'Junio C Hamano
Typofix. * do/gitweb-typofix-in-comments: gitweb: fix a couple spelling errors in comments
2020-01-05gitweb: fix a couple spelling errors in commentsDenis Ovsienko
Signed-off-by: Denis Ovsienko <denis@ovsienko.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-01Merge branch 'jk/gitweb-anti-xss'Junio C Hamano
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
2019-12-01Merge branch 'en/doc-typofix'Junio C Hamano
Docfix. * en/doc-typofix: Fix spelling errors in no-longer-updated-from-upstream modules multimail: fix a few simple spelling errors sha1dc: fix trivial comment spelling error Fix spelling errors in test commands Fix spelling errors in messages shown to users Fix spelling errors in names of tests Fix spelling errors in comments of testcases Fix spelling errors in code comments Fix spelling errors in documentation outside of Documentation/ Documentation: fix a bunch of typos, both old and new
2019-11-18gitweb: escape URLs generated by href()Jeff King
There's a cross-site scripting problem in gitweb, where it will print URLs generated by its href() helper without further quoting. This allows an attacker to point a victim to a specially crafted gitweb URL and inject arbitrary HTML into the resulting page (which the victim sees as coming from gitweb). The base of the URL comes from evaluate_uri(), which pulls the value of $REQUEST_URI via the CGI module. It tries to strip off $PATH_INFO, but fails to do so in some cases (including ones that contain special characters, like "+"). Most of the uses of the URL end up being passed to "$cgi->a(-href = href())", which will get quoted properly by the CGI module. But in a few places, we output them ourselves as part of manually-generated HTML, and whatever was in the original URL will appear unquoted in the output. Given that all of the nearby variables placed into this manual HTML _are_ quoted, it seems like the authors assumed that these URLs would not need quoting. So it's possible that the bug is actually in evaluate_uri(), which should be doing a more careful job of stripping $PATH_INFO. There's some discussion in a comment in that function, as well as the commit message in 81d3fe9f48 (gitweb: fix wrong base URL when non-root DirectoryIndex, 2009-02-15). But I'm not sure I understand it. Regardless, it's a good idea to quote these values at the point of insertion into the HTML output: 1. Even if there is a bug in evaluate_uri(), this would give us belt-and-suspenders protection. 2. evaluate_uri() is only handling the base. Some generated URLs will also mention arbitrary refs or filenames in the repositories, and these should be quoted anyway. 3. It should never _hurt_ to quote (and that's what all of the $cgi->a() calls are doing already). So there may be further work here, but this patch at least prevents the XSS vulnerability, and shouldn't make anything worse. The test here covers the calls in print_feed_meta(), but I manually audited every call to href() to see how its output was used, and quoted appropriately. Most of them are esc_attr(), as they're used in tag attributes, but I used esc_html() when the URLs were printed bare. The distinction is largely academic, as one is implemented as a wrapper for the other. Reported-by: NAKAYAMA DAISUKE <nakyamad@icloud.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in code commentsElijah Newren
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28gitweb: correctly store previous rev in javascript-actions modeRobert Luberda
Without this change, the setting $feature{'javascript-actions'}{'default'} = [1]; in gitweb.conf breaks gitweb's blame page: clicking on line numbers displayed in the second column on the page has no effect. For comparison, with javascript-actions disabled, clicking on line numbers loads the previous version of the line. Addresses https://bugs.debian.org/741883. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Robert Luberda <robert@debian.org> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-01gitweb: make hash size independentbrian m. carlson
Gitweb has several hard-coded 40 values throughout it to check for values that are passed in or acquired from Git. To simplify the code, introduce a regex variable that matches either exactly 40 or exactly 64 hex characters, and use this variable anywhere we would have previously hard-coded a 40 in a regex. Add some helper functions which allow us to write tighter regexes that match exactly the number of hex characters we're expecting. Similarly, switch the code that looks for deleted diffinfo information to look for either 40 or 64 zeros, and update one piece of code to use this function. Finally, when formatting a log line, allow an abbreviated describe output to contain up to 64 characters. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05gitweb: hard-depend on the Digest::MD5 5.8 moduleÆvar Arnfjörð Bjarmason
Since my d48b284183 ("perl: bump the required Perl version to 5.8 from 5.6.[21]", 2010-09-24), we've depended on 5.8, so there's no reason to conditionally require Digest::MD5 anymore. It was released with perl v5.7.3[1] The initial introduction of the dependency in e9fdd74e53 ("gitweb: (gr)avatar support", 2009-06-30) says as much, this also undoes part of the later 2e9c8789b7 ("gitweb: Mention optional Perl modules in INSTALL", 2011-02-04) since gitweb will always be run on at least 5.8, so there's no need to mention Digest::MD5 as a required module in the documentation, let's instead say that we require perl 5.8. 1. $ corelist Digest::MD5 Data for 2015-02-14 Digest::MD5 was first released with perl v5.7.3 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06Merge branch 'gc/gitweb-filetest-acl'Junio C Hamano
"gitweb" checks if a directory is searchable with Perl's "-x" operator, which can be enhanced by using "filetest 'access'" pragma, which now we do. * gc/gitweb-filetest-acl: gitweb: use filetest to allow ACLs
2017-10-24gitweb: use filetest to allow ACLsGuillaume Castagnino
In commit 46a1385 (gitweb: skip unreadable subdirectories, 2017-07-18) we forgot to handle non-unix ACLs as well. Fix this. Signed-off-by: Guillaume Castagnino <casta@xwing.info> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-27Merge branch 'js/gitweb-raw-blob-link-in-history'Junio C Hamano
"gitweb" shows a link to visit the 'raw' contents of blbos in the history overview page. * js/gitweb-raw-blob-link-in-history: gitweb: add 'raw' blob_plain link in history overview
2017-08-24Merge branch 'hb/gitweb-project-list' into maintJunio C Hamano
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
2017-08-22gitweb: add 'raw' blob_plain link in history overviewJob Snijders
For people that work with very large plain text files it may be easier if one can bypass viewing the htmlized blob and instead click directly to the raw file (rather then click through 'blob' and then to 'raw'). Signed-off-by: Job Snijders <job@instituut.net> Reviewed-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-11Merge branch 'hb/gitweb-project-list'Junio C Hamano
When a directory is not readable, "gitweb" fails to build the project list. Work this around by skipping such a directory. * hb/gitweb-project-list: gitweb: skip unreadable subdirectories
2017-07-18gitweb: skip unreadable subdirectoriesHielke Christian Braun
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 <hcb@unco.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-27Spelling fixesVille Skyttä
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-15doc: use https links to Wikipedia to avoid http redirectsSven Strickroth
Signed-off-by: Sven Strickroth <email@cs-ware.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Merge branch 'ab/gitweb-abbrev-links'Junio C Hamano
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
2016-10-14gitweb: link to "git describe"'d commits in log messagesÆvar Arnfjörð Bjarmason
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 <avarab@gmail.com> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-14gitweb: link to 7-char+ SHA-1s, not only 8-char+Ævar Arnfjörð Bjarmason
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 <avarab@gmail.com> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-14gitweb: fix a typo in a commentÆvar Arnfjörð Bjarmason
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 <avarab@gmail.com> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26gitweb: use highlight's shebang detectionIan Kelling
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 <ian@iankelling.org> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26gitweb: remove unused guess_file_syntax() parameterIan Kelling
Signed-off-by: Ian Kelling <ian@iankelling.org> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01gitweb: escape link body in format_ref_markerAndreas Brauchli
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 <a.brauchli@elementarea.net> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>