mirror of
https://git.zx2c4.com/cgit
synced 2024-11-22 08:28:42 +00:00
A hyperfast web frontend for git repositories written in C.
30304d8156
Teach the "log" UI to behave in the same way as "git log --follow", when given a suitable instruction by the user. The default behaviour remains to show the log without following renames, but the follow behaviour can be activated by following a link in the page header. Follow is not the default because outputting merges in follow mode is tricky ("git log --follow" will not show merges). We also disable the graph in follow mode because the commit graph is not simplified so we end up with frequent gaps in the graph and many lines that do not connect with any commits we're actually showing. We also teach the "diff" and "commit" UIs to respect the follow flag on URLs, causing the single-file version of these UIs to detect renames. This feature is needed only for commits that rename the path we're interested in. For commits before the file has been renamed (i.e. that appear later in the log list) we change the file path in the links from the log to point to the old name; this means that links to commits always limit by the path known to that commit. If we didn't do this we would need to walk down the log diff'ing every commit whenever we want to show a commit. The drawback is that the "Log" link in the top bar of such a page links to the log limited by the old name, so it will only show pre-rename commits. I consider this a reasonable trade-off since the "Back" button still works and the log matches the path displayed in the top bar. Since following renames requires running diff on every commit we consider, I've added a knob to the configuration file to globally enable/disable this feature. Note that we may consider a large number of commits the revision walking machinery no longer performs any path limitation so we have to examine every commit until we find a page full of commits that affect the target path or something related to it. Suggested-by: René Neumann <necoro@necoro.eu> Signed-off-by: John Keeping <john@keeping.me.uk> |
||
---|---|---|
contrib/hooks | ||
filters | ||
git@a17c56c056 | ||
tests | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
AUTHORS | ||
cache.c | ||
cache.h | ||
cgit-doc.css | ||
cgit.c | ||
cgit.css | ||
cgit.h | ||
cgit.mk | ||
cgit.png | ||
cgitrc.5.txt | ||
cmd.c | ||
cmd.h | ||
configfile.c | ||
configfile.h | ||
COPYING | ||
favicon.ico | ||
filter.c | ||
gen-version.sh | ||
html.c | ||
html.h | ||
Makefile | ||
parsing.c | ||
README | ||
robots.txt | ||
scan-tree.c | ||
scan-tree.h | ||
shared.c | ||
ui-atom.c | ||
ui-atom.h | ||
ui-blob.c | ||
ui-blob.h | ||
ui-clone.c | ||
ui-clone.h | ||
ui-commit.c | ||
ui-commit.h | ||
ui-diff.c | ||
ui-diff.h | ||
ui-log.c | ||
ui-log.h | ||
ui-patch.c | ||
ui-patch.h | ||
ui-plain.c | ||
ui-plain.h | ||
ui-refs.c | ||
ui-refs.h | ||
ui-repolist.c | ||
ui-repolist.h | ||
ui-shared.c | ||
ui-shared.h | ||
ui-snapshot.c | ||
ui-snapshot.h | ||
ui-ssdiff.c | ||
ui-ssdiff.h | ||
ui-stats.c | ||
ui-stats.h | ||
ui-summary.c | ||
ui-summary.h | ||
ui-tag.c | ||
ui-tag.h | ||
ui-tree.c | ||
ui-tree.h |
cgit - CGI for Git ================== This is an attempt to create a fast web interface for the Git SCM, using a built-in cache to decrease server I/O pressure. Installation ------------ Building cgit involves building a proper version of Git. How to do this depends on how you obtained the cgit sources: a) If you're working in a cloned cgit repository, you first need to initialize and update the Git submodule: $ git submodule init # register the Git submodule in .git/config $ $EDITOR .git/config # if you want to specify a different url for git $ git submodule update # clone/fetch and checkout correct git version b) If you're building from a cgit tarball, you can download a proper git version like this: $ make get-git When either a) or b) has been performed, you can build and install cgit like this: $ make $ sudo make install This will install `cgit.cgi` and `cgit.css` into `/var/www/htdocs/cgit`. You can configure this location (and a few other things) by providing a `cgit.conf` file (see the Makefile for details). If you'd like to compile without Lua support, you may use: $ make NO_LUA=1 And if you'd like to specify a Lua implementation, you may use: $ make LUA_PKGCONFIG=lua5.1 If this is not specified, the Lua implementation will be auto-detected, preferring LuaJIT if many are present. Acceptable values are generally "lua", "luajit", "lua5.1", and "lua5.2". Dependencies ------------ * libzip * libcrypto (OpenSSL) * libssl (OpenSSL) * optional: luajit or lua, most reliably used when pkg-config is available Apache configuration -------------------- A new `Directory` section must probably be added for cgit, possibly something like this: <Directory "/var/www/htdocs/cgit/"> AllowOverride None Options +ExecCGI Order allow,deny Allow from all </Directory> Runtime configuration --------------------- The file `/etc/cgitrc` is read by cgit before handling a request. In addition to runtime parameters, this file may also contain a list of repositories displayed by cgit (see `cgitrc.5.txt` for further details). The cache --------- When cgit is invoked it looks for a cache file matching the request and returns it to the client. If no such cache file exists (or if it has expired), the content for the request is written into the proper cache file before the file is returned. If the cache file has expired but cgit is unable to obtain a lock for it, the stale cache file is returned to the client. This is done to favour page throughput over page freshness. The generated content contains the complete response to the client, including the HTTP headers `Modified` and `Expires`. Online presence --------------- * The cgit homepage is hosted by cgit at <http://git.zx2c4.com/cgit/about/> * Patches, bug reports, discussions and support should go to the cgit mailing list: <cgit@lists.zx2c4.com>. To sign up, visit <http://lists.zx2c4.com/mailman/listinfo/cgit>