Batch output of git-cat-file has the form:
<sha1> SP <type> SP <size> LF <contents> LF
It unconditionally includes a trailing line-feed which Repo.blob()
incorrectly returns as part of blob content. For textual blobs, this
extra character is often benign, however, for binary blobs, it can
easily change the meaning of the data in unexpected or disastrous ways.
Fix this by respecting the blob size reported by git-cat-file.
(The alternate approach of unconditionally dropping the final LF also
works, however, respecting the reported size is perhaps a bit more
robust and "correct".)
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Historically, the 'blob' view was unconditionally handed cooked
(utf8-encoded) blob content, so embed_image_blob(), which requires raw
blob content, has been forced to reload the blob in raw form, which is
ugly and expensive. However, now that the Blob returned by Repo.blob()
is able to vend raw or cooked content, it is no longer necessary for
embed_image_blob() to reload the blob to gain access to the raw content.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Some blob representations require raw blob content, however, the 'blob'
view is unconditionally handed cooked (utf8-encoded) content, thus
representations which need raw content are forced to reload the blob in
raw form, which is ugly and expensive.
The ultimate goal is to eliminate the wasteful blob reloading when raw
content is needed. Toward that end, teach Blob how to vend raw or cooked
content.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Some blob representations (such as embedded images) require raw blob
content, however, the 'blob' view is unconditionally handed cooked
(utf8-encoded) content, thus representations which need raw content are
forced to reload the blob in raw form, which is ugly and expensive (due
to shelling out to git-cat-file a second time).
The ultimate goal is to eliminate the wasteful blob reloading when raw
content is needed. As a first step, introduce a Blob abstraction to be
returned by Repo.blob() rather than the cooked content. A subsequent
change will flesh out Blob, allowing it to return raw or cooked content
on demand without the client having to specify one or the other when
invoking Repo.blob().
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Sneakily extracting the raw 'fd' from the utf8-encoding wrapper
returned by GitCommand.run() is ugly and fragile. Instead, take
advantage of the new formal API for requesting raw command output.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Currently, clients which want the raw output from a Git command must
sneakily extract the raw 'fd' from the utf8-encoding wrapper returned
by GitCommand.run(). This is ugly and fragile. Instead, provide a
formal mechanism for requesting raw output.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Currently, clients which want the raw output from a Git command must
sneakily extract the raw 'fd' from the utf8-encoding wrapper returned
by run_git(). This is ugly and fragile. Instead, provide a formal
mechanism for requesting raw output.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
The 'max_pages' default value of 5 is quite low. Coupled with
'commits_per_page' default 50, this allows for only 250 commits, which
is likely unsuitable for even relatively small projects. Options are to
remove the cap altogether or to raise the default limit. At this time,
choose the latter, which should be friendlier to larger projects, in
general, while still guarding against run-away storage space
consumption.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Branch names in Git may be hierarchical (for example, "wip/parser/fix"),
however, git-arr's Bottle routing rules do not take this into account.
Fix this shortcoming.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Branch names in Git may be hierarchical (for example, "wip/parser/fix"),
however, git-arr does not take this into account in its Bottle routing
rules.
Unfortunately, when updated to recognize hierarchical branch names, the
rules become ambiguous in their present order since Bottle matches them
in the order registered. The ambiguity results in incorrect matches. For
instance, branch pages (/r/<repo>/b/<bname>/) are matched before tree
pages (/r/<repo>/b/<bname>/t/), however, when branch names can be
hierarchical, a tree path such as "/r/proj/b/branch/t/" also looks like
a branch named "branch/t", and thus undesirably matches the branch rule
rather than the tree rule. This problem can be resolved by adjusting the
order of rules.
Therefore, re-order the rules from most to least specific as a
preparatory step prior to actually fixing them to accept hierarchical
branch names. This is a purely textual relocation. No functional
changes intended.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Git branch names can be hierarchical (for example, "wip/parser/fix"),
however, git-arr does not take this into account when formulating URLs
on branch, tree, and blobs pages. These URLs are dysfunctional because
it is assumed incorrectly that a single "../" is sufficient to climb
over the branch name when computing relative paths to resources higher
in the hierarchy. This problem manifests as failure to load static
resources (stylesheet, etc.), broken links to commits on branch pages,
and malfunctioning breadcrumb trails.
Fix this problem by computing the the proper number of "../" based upon
the branch name, rather than assuming that a single "../" will work
unconditionally. (This is analogous to the treatment already given to
hierarchical pathnames in tree and blob views.)
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Pagination link "next" does not respect 'max_pages', thus it incorrectly
remains enabled on the final page capped by 'max_pages'. When clicked,
the user is taken to a "404 Page not found" error page, which makes for
a poor user experience.
Fix this problem by teaching the "next" link to respect 'max_pages'.
(As a side-effect, this also causes 'serve' mode to respect 'max_pages',
which was not previously the case. This change of behavior is
appropriate since it brings 'serve' mode, which is intended primarily
for testing, more in line with 'generate' mode.)
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
When the number of commits on a branch page is less than
'commits_per_page', the pagination "next" link is disabled, indicating
correctly that this is the final page. However, if the number of commits
on the branch page is exactly 'commits_per_page', then the "next" link
is incorrectly enabled, even on the final page. When clicked, the user
is taken to a "404 Page not found" error page, which makes for a poor
user experience.
Fix this problem by reliably detecting when the branch page is the final
one. Do so by asking for (but not displaying) one commit more than
actually needed by the page. If the additional commit is successfully
retrieved, then another page definitely follows this one. If not
retrieved, then this is definitely the final page.
(Unfortunately, the seemingly more expedient approach of checking if the
final commit on the current page is a root commit -- has no parents --
is not a reliable indicator that this the final page since a branch may
have multiple root commits due to merging.)
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
At its inception, Git did not show a "creation event" diff for a
project's root commit since early projects, such as the Linux kernel,
were already well established, and a large root diff was considered
uninteresting noise.
On the other hand, new projects adopting Git typically have small root
commits, and such a "creation event" is likely to have meaning, rather
than being pure noise. Consequently, git-diff-tree gained a --root flag
in dc26bd89 (diff-tree: add "--root" flag to show a root commit as a big
creation event, 2005-05-19), though it was disabled by default.
Displaying the root "creation event" diff, however, became the default
behavior when configuration option 'log.showroot' was added to git-log
in 0f03ca94 (config option log.showroot to show the diff of root
commits; 2006-11-23). And, gitk (belatedly) followed suit when it
learned to respect 'log.showroot' in b2b76d10 (gitk: Teach gitk to
respect log.showroot; 2011-10-04).
By default, these tools now all show the root diff as a "creation
event", however, git-arr suppresses it unconditionally. Resolve this
shortcoming by adding a new git-arr configuration option "rootdiff" to
control the behavior (enabled by default).
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
By default, git-arr limits the number of pages of commits to 5, however,
it is reasonable to expect that some projects will want all commits to
be shown. Rather than forcing such projects to choose an arbitrarily
large number as the value of 'max_pages', provide a formal mechanism to
specify unlimited commit pages.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
When emitting a blob in the root tree of a commit, write_tree() composes
the blob's HTML filename with an extra slash before the "f=", like this:
output/r/repo/b/master/t//f=README.txt.html
Although the double-slash is not harmful on Unix, it is unsightly, and
may be problematic for other platforms or filesystems which interpret
double-slash specially or disallow it. Therefore, suppress the extra
slash for blobs in the root tree.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
A human-readable representation of a Git SHA1 commit ID is composed
only of hexadecimal digits, thus there is no need to match against
the full alphabet.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
When a repository has a "master" branch, a short summary of its most
recent commits is shown, followed by a horizontal rule. If there is no
"master" branch, then the commit summary is suppressed, however, the
rule is shown unconditionally, which is ugly, particularly when there
is already a rule following the web_url/git_url block. Therefore,
suppress the "master" branch horizontal rule when not needed. (This is
analogous to how the rule following the web_url/git_url block is
suppressed when that information is not shown).
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
These repo-specific options were added in 54026b75 (Make embedding
markdown and images configurable per-repo, 2013-11-02) but not
documented.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
If there is a branch and a file with the same name, git-arr will fail to
generate, as git will complain when running git rev-list.
For example, if there is both a file and a branch called "hooks" in the
repository, git-arr would fail as follows:
=== git-arr running: ['git', '--git-dir=/some/repo', 'rev-list', '--max-count=1', '--header', u'hooks'])
fatal: ambiguous argument 'hooks': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Traceback (most recent call last):
File "./git-arr", line 457, in <module>
main()
File "./git-arr", line 452, in main
skip_index = len(opts.only) > 0)
File "./git-arr", line 388, in generate
branch_mtime = r.commit(bn).committer_date.epoch
AttributeError: 'NoneType' object has no attribute 'committer_date'
To fix that, this patch appends a "--" as the last argument to rev-list, which
indicates that it has completed the revision list, which disambiguates the
argument.
While at it, a minor typo in a comment is also fixed.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
The current parsing of dates from git incorrectly uses
datetime.fromtimestamp(), which returns the *local* date and time
corresponding to the given timestamp.
Instead, it should be using datetime.utcfromtimestamp() which returns the UTC
date and time, as the rest of the code expects.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Some versions of bottle.py don't deal well with the "if" inside the lambda, so
work around it by just using comparison and simplifying the function.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
The missing '% end' template keyword to these one-line if statements was
causing bottle 0.12.7 to incorrectly indent the following line, leading to an
IndentationError at runtime when the blob and tree templates are compiled.
Signed-off-by: Vanya Sergeev <vsergeev@gmail.com>
The commit view shows the author information in the committer field; this
patch fixes it by showing the appropriate fields.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
It turned out that bottle.py is not backwards-compatible with the status code
change: older versions encode the status in e.status; newer ones use
e.status_code (and e.status became a string).
This patch works around that by trying to pick up which of the two variants we
have, and deciding accordingly.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch adds the age of the repository to the index view, using javascript
to give a nice human string for the age.
When javascript is not available, the element remains hidden.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
Newer versions of bottle have a string in the e.status attribute, and the
status code can be found in e.status_code, which should be backwards
compatible.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch introduces the embed_markdown and embed_images configuration
options, so users can enable and disable those features on a per-repository
basis.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch makes minor changes to the code that handles embedded images,
mostly to make it use mimetypes, and to remove SVG support (at least for now)
due to security concerns.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch adds a post-receive hook that can be used to trigger a git-arr
update when there is a push to a repository.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
When the tool is invoked like /path/to/git-arr, it currently fails because
both the serving of static files and bottle templates assume they're on the
current working directory.
This patch fixes that by computing the directories based on the executable
location.
Note this is assuming the static directory and the templates live next to the
executable, which will not always be the case, and eventually it should be
configurable; but it's ok for the time being.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch fixes the --only option, and makes it avoid generating the
top-level index so we don't get a broken one with only the specified
repositories.
The intention is that this option is used in hooks to update the views after a
commit or push.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
The lexer guesser based on content is often wrong; to minimize the chances of
that happening, we only use it on files that start with "#!", for which it
usually has smarter rules.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
If we can't guess the lexer by the file name, try to guess based on the
content.
This allows pygments to colorize extension-less files, usually scripts.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
In practise pygments seems to have a very hard time processing large files and
files with long lines, so try to avoid using it in those cases.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
This patch improves the way we find the path to the repositories, both in the
recursive and in the non-recursive cases.
We now support specifying non-bare repositories directly, and also recursing
on them.
Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
