tornadocontrib/git-arr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
dff4ff6757
git-arr/views/blob.html

93 lines
2.3 KiB
HTML
Raw Normal View History

views: Improve display on mobile browsers This patch moves the pages to HTML5, and adds some simple meta tags and CSS media constraints so things render better on mobile browsers, while leaving the desktop unaffected. It's still not ideal, though. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-11-18 02:05:13 +02:00
<!DOCTYPE html>
<html>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
<head>
% if not dirname.raw:
views: fix broken URLs involving hierarchical branch names 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>
2014-12-31 11:50:08 +02:00
% reltree = './'
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% else:
views: fix broken URLs involving hierarchical branch names 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>
2014-12-31 11:50:08 +02:00
% reltree = '../' * (len(dirname.split('/')) - 1)
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% end
blob: pass branch name to view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:33 +02:00
% relroot = reltree + '../' * (len(branch.split('/')) - 1)
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
<title>git &raquo; {{repo.name}} &raquo;
Simplify smstr With the Python 2 to 3 migration and the type checking, we can be fairly confident that smstr are always constructed from strings, not bytes. This allows the code to be simplified, as we no longer need to carry the dual raw/unicode representation.
2020-05-24 17:52:11 +03:00
{{branch}} &raquo; {{dirname.raw}}{{fname.raw}}</title>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
<link rel="stylesheet" type="text/css"
href="{{relroot}}../../../../../static/git-arr.css"/>
<link rel="stylesheet" type="text/css"
href="{{relroot}}../../../../../static/syntax.css"/>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
views: Improve display on mobile browsers This patch moves the pages to HTML5, and adds some simple meta tags and CSS media constraints so things render better on mobile browsers, while leaving the desktop unaffected. It's still not ideal, though. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-11-18 02:05:13 +02:00
<meta name=viewport content="width=device-width, initial-scale=1">
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</head>
<body class="tree">
<h1><a href="{{relroot}}../../../../../">git</a> &raquo;
<a href="{{relroot}}../../../">{{repo.name}}</a> &raquo;
blob: pass branch name to view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:33 +02:00
<a href="{{reltree}}../">{{branch}}</a> &raquo;
views: fix broken URLs involving hierarchical branch names 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>
2014-12-31 11:50:08 +02:00
<a href="{{reltree}}">tree</a>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</h1>
<h3>
blob: pass branch name to view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:33 +02:00
<a href="{{reltree}}">[{{branch}}]</a> /
views: fix broken URLs involving hierarchical branch names 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>
2014-12-31 11:50:08 +02:00
% base = smstr(reltree)
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% for c in dirname.split('/'):
Fix one-line 'if' termination in tree, blob templates 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>
2014-06-30 09:02:18 +03:00
% if not c.raw:
% continue
% end
Simplify smstr With the Python 2 to 3 migration and the type checking, we can be fairly confident that smstr are always constructed from strings, not bytes. This allows the code to be simplified, as we no longer need to carry the dual raw/unicode representation.
2020-05-24 17:52:11 +03:00
<a href="{{base.url}}{{c.url}}/">{{c.raw}}</a> /
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% base += c + '/'
% end
<a href="">{{!fname.html}}</a>
</h3>
views: blob: render empty blobs specially Empty (zero-length) blobs are currently rendered by 'pygments' misleadingly as a single empty line, or, when 'pygments' is unavailable, as "nothingness" preceding a horizontal rule. In either case, it is somewhat difficult to glean concrete information about the blob. Address this by instead rendering summary information about the blob: in particular, its classification ("empty") and its size ("0 bytes"). This is analogous to the summary information rendered for binary blobs ("binary" and size). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:16 +02:00
% if len(blob.raw_content) == 0:
<table class="nice">
<tr>
<td>empty &mdash; 0 bytes</td>
</tr>
</table>
Simplify smstr With the Python 2 to 3 migration and the type checking, we can be fairly confident that smstr are always constructed from strings, not bytes. This allows the code to be simplified, as we no longer need to carry the dual raw/unicode representation.
2020-05-24 17:52:11 +03:00
% elif can_embed_image(repo, fname.raw):
embed_image_blob: retire reload of image blob 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>
2015-01-13 11:57:11 +02:00
{{!embed_image_blob(fname.raw, blob.raw_content)}}
blob: render binary blob summary information rather than raw content Binary blobs are currently rendered as raw data directly into the HTML output, looking much like "line noise". This is rarely, if ever, meaningful, and consumes considerable storage space since the entire raw blob content is embedded in the generated HTML file. Address this issue by instead emitting summary information about the blob, such as its classification ("binary") and its size. Other information can be added as needed. As in Git itself, a blob is considered binary if a NUL is present in the first ~8KB. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:13 +02:00
% elif is_binary(blob.raw_content):
blob: render hexdump(1)-style binary blob content Raw binary blob content tends to look like "line noise" and is rarely, if ever, meaningful. A hexdump(1)-style rendering (specifically, "hexdump -C"), on the other hand, showing runs of hexadecimal byte values along with an ASCII representation of those bytes can sometimes reveal useful information about the data. (A subsequent patch will add the ability to cap the amount of data rendered in order to reduce storage space requirements.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:14 +02:00
<table class="nice blob-binary">
blob: render binary blob summary information rather than raw content Binary blobs are currently rendered as raw data directly into the HTML output, looking much like "line noise". This is rarely, if ever, meaningful, and consumes considerable storage space since the entire raw blob content is embedded in the generated HTML file. Address this issue by instead emitting summary information about the blob, such as its classification ("binary") and its size. Other information can be added as needed. As in Git itself, a blob is considered binary if a NUL is present in the first ~8KB. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:13 +02:00
<tr>
blob: render hexdump(1)-style binary blob content Raw binary blob content tends to look like "line noise" and is rarely, if ever, meaningful. A hexdump(1)-style rendering (specifically, "hexdump -C"), on the other hand, showing runs of hexadecimal byte values along with an ASCII representation of those bytes can sometimes reveal useful information about the data. (A subsequent patch will add the ability to cap the amount of data rendered in order to reduce storage space requirements.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:14 +02:00
<td colspan="4">
blob: render binary blob summary information rather than raw content Binary blobs are currently rendered as raw data directly into the HTML output, looking much like "line noise". This is rarely, if ever, meaningful, and consumes considerable storage space since the entire raw blob content is embedded in the generated HTML file. Address this issue by instead emitting summary information about the blob, such as its classification ("binary") and its size. Other information can be added as needed. As in Git itself, a blob is considered binary if a NUL is present in the first ~8KB. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:13 +02:00
binary &mdash; {{'{:,}'.format(len(blob.raw_content))}} bytes
</td>
</tr>
blob: cap amount of rendered binary blob content Although hexdump(1)-style rendering of binary blob content may reveal some meaningful information about the data, it wastes even more storage space than embedding the raw data itself. However, many binary files have a "magic number" or other signature near the beginning of the file, so it is often possible to glean useful information from just the initial chunk of the file without having the entire content available. Thus, limiting the rendered data to just an initial chunk saves storage space while still potentially presenting useful information about the binary content. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:15 +02:00
% lim = 256
% for offset, hex1, hex2, text in hexdump(blob.raw_content[:lim]):
blob: render hexdump(1)-style binary blob content Raw binary blob content tends to look like "line noise" and is rarely, if ever, meaningful. A hexdump(1)-style rendering (specifically, "hexdump -C"), on the other hand, showing runs of hexadecimal byte values along with an ASCII representation of those bytes can sometimes reveal useful information about the data. (A subsequent patch will add the ability to cap the amount of data rendered in order to reduce storage space requirements.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:14 +02:00
<tr>
<td class="offset">{{offset}}</td>
<td><pre>{{hex1}}</pre></td>
<td><pre>{{hex2}}</pre></td>
<td><pre>{{text}}</pre></td>
</tr>
% end
blob: cap amount of rendered binary blob content Although hexdump(1)-style rendering of binary blob content may reveal some meaningful information about the data, it wastes even more storage space than embedding the raw data itself. However, many binary files have a "magic number" or other signature near the beginning of the file, so it is often possible to glean useful information from just the initial chunk of the file without having the entire content available. Thus, limiting the rendered data to just an initial chunk saves storage space while still potentially presenting useful information about the binary content. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:15 +02:00
% if lim < len(blob.raw_content):
<tr class="etc">
<td></td>
<td>&hellip;</td>
<td>&hellip;</td>
<td>&hellip;</td>
</tr>
% end
blob: render binary blob summary information rather than raw content Binary blobs are currently rendered as raw data directly into the HTML output, looking much like "line noise". This is rarely, if ever, meaningful, and consumes considerable storage space since the entire raw blob content is embedded in the generated HTML file. Address this issue by instead emitting summary information about the blob, such as its classification ("binary") and its size. Other information can be added as needed. As in Git itself, a blob is considered binary if a NUL is present in the first ~8KB. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-13 11:57:13 +02:00
</table>
Simplify smstr With the Python 2 to 3 migration and the type checking, we can be fairly confident that smstr are always constructed from strings, not bytes. This allows the code to be simplified, as we no longer need to carry the dual raw/unicode representation.
2020-05-24 17:52:11 +03:00
% elif can_markdown(repo, fname.raw):
Tune markdown CSS to increase readability The default CSS is not very comfortable for markdown, as for example the links are hidden. This patch makes the markdown CSS tunable by wrapping it into a div, and then adjusting the default styles to increase readability.
2018-03-04 22:06:41 +03:00
<div class="markdown">
git.py: introduce Blob abstraction 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>
2015-01-13 11:57:09 +02:00
{{!markdown_blob(blob.utf8_content)}}
Tune markdown CSS to increase readability The default CSS is not very comfortable for markdown, as for example the links are hidden. This patch makes the markdown CSS tunable by wrapping it into a div, and then adjusting the default styles to increase readability.
2018-03-04 22:06:41 +03:00
</div>
git.py: introduce Blob abstraction 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>
2015-01-13 11:57:09 +02:00
% elif can_colorize(blob.utf8_content):
css: Work around Pygments' element layout changes Pygments 2.12 changes the element layout slightly, adding a wrapper <div> that was accidentally removed before: https://github.com/pygments/pygments/issues/632. This patch adds a workaround, so the styling is consistent on both 2.11 and 2.12.
2022-09-26 04:43:55 +03:00
<div class="colorized-src">
Simplify smstr With the Python 2 to 3 migration and the type checking, we can be fairly confident that smstr are always constructed from strings, not bytes. This allows the code to be simplified, as we no longer need to carry the dual raw/unicode representation.
2020-05-24 17:52:11 +03:00
{{!colorize_blob(fname.raw, blob.utf8_content)}}
css: Work around Pygments' element layout changes Pygments 2.12 changes the element layout slightly, adding a wrapper <div> that was accidentally removed before: https://github.com/pygments/pygments/issues/632. This patch adds a workaround, so the styling is consistent on both 2.11 and 2.12.
2022-09-26 04:43:55 +03:00
</div>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% else:
<pre class="blob-body">
git.py: introduce Blob abstraction 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>
2015-01-13 11:57:09 +02:00
{{blob.utf8_content}}
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</pre>
% end
<hr/>
</body>
</html>
Reference in New Issue Copy Permalink