Browse (or manifest) action allows browsing the directory structure at some
specified revision. In gitweb and monoblue styles, the revision header already
has branch/tag/bookmark information for the revision, but in paper style this
header was only showing tags. This patch adds branches and bookmarks.
Branch name needs to be obtained in this special way to be consistent with
regular changeset page, where in paper style default branch is never shown.
This line for filelogentry template is copied from shortlogentry. The
information is already displayed in paper style, so no change to python code is
needed. Tests are unaffected.
There already are branches and tags in file log, now let's add what's been
missing: bookmarks.
Also, since coal borrows this template from paper, this change is effective for
coal as well.
This will ease future patches for the templates.
As a result of this patch, paper style has one visual change in
log/shortlog/file log view: the spacing between commit message and the first
tag (or branch name, or bookmark) is now roughly who spaces wide instead of one
space wide. This spacing is consistent with the one between branch
names/tags/bookmarks themselves, so it looks better.
In gitweb style, the change from non-breakable space to regular space is
consistent with other elements.
In monoblue the change is not noticeable.
This also adds labels to the output, as the tests now show.
I took the liberty to give two labels to the bisection status, just
like revisions get the log.changeset and changeset.phase statuses.
It appears that git users like having a --name-status option on `git
log`. There exist at least three questions on StackOverflow on how to
do this for hg. The desired output is not difficult to build with
templates, and since this is something that svn users might also want,
it seems desirable to have this as another standard template.
This mimics the output of `hg status` and adds it to the log output.
It also follows status's convention of displaying copies with a -C
option. Brief example:
$ hg log -T status -C
changeset: 24883:7d1b9b7ac9fd
bookmark: statustemplate
tag: tip
parent: 24864:a08f05e3a9cf
user: Jordi Gutiérrez Hermoso <jordigh@octave.org>
date: Wed Apr 22 14:05:04 2015 -0400
summary: log: add a status template
files:
A added
A copied
original
M modified
R removed
Of course, everything is also coloured correctly, and there are tests
to prove it.
It's easy to miss the closing </tr> tag when it's not on its own line. Some
neighboring blocks also already use this clearer style.
(In 7e841ecf66c5 I didn't even think grepping for this, but this patch should
now cover every occurrence).
Since e902e55c3d0b, column headers are wrapped by <thead> element, so the first
and only <tbody> contains changelog data. I got the following error without
this patch:
Uncaught TypeError: Cannot read property 'lastElementChild' of null
scrollHandler @ mercurial.js:375
This is a copy of 942d64e0a1ee, but applied to the phases template,
which is itself almost a copy of the default template.
Perhaps we should rewrite these templates to use the %include syntax
afforded by config files. This change seems a bit too big for stable,
though.
Single letter properties are used to keep payload size down, as diff
representation can be quite large and longer property names can create a
lot of extra work for parsers.
Rename is not yet captured. This can be done in a follow-up.
We should consider add HTML rendering of the RST into the response as a
follow-up. I attempted to do this, but there was an empty array
returned by the rstdoc() template function. Not sure what's going on.
Will deal with it later.
These are the same dispatch function under the hood. The only difference
is the default number of entries to render and the template to use. So
it makes sense to use a shared template.
Format for {changelistentry} is similar to {changeset}. However, there
are differences to argument names and their values preventing us from
(easily) using the same template. (Perhaps there is room to consolidate
the templates as a follow-up.)
We're currently not recording some data in {changelistentry} that exists
in {changeset}. This includes the branch name. This should be added in
a follow-up. For now, something is better than nothing.
It's pretty surprising phase wasn't part of this template call already.
We now expose {phase} to the {changeset} template and we expose this
data to JSON.
This brings JSON output in line with the output from `hg log -Tjson`.
The lone exception is hweb doesn't print the numeric rev. As has been
stated previously, I don't believe hgweb should be exposing these
unstable identifiers. (We can add them later if we really want them.)
There is still work to bring hgweb in parity with --verbose and
--debug output from the CLI.
Tags is pretty easy to implement. Let's start there.
The output is slightly different from `hg tags -Tjson`. For reference,
the CLI has the following output:
[
{
"node": "e2049974f9a23176c2addb61d8f5b86e0d620490",
"rev": 29880,
"tag": "tip",
"type": ""
},
...
]
Our output has the format:
{
"node": "0aeb19ea57a6d223bacddda3871cb78f24b06510",
"tags": [
{
"node": "e2049974f9a23176c2addb61d8f5b86e0d620490",
"tag": "tag1",
"date": [1427775457.0, 25200]
},
...
]
}
"rev" is omitted because it isn't a reliable identifier. We shouldn't
be exposing them in web APIs and giving the impression it remotely
resembles a stable identifier. Perhaps we could one day hide this behind
a config option (it might be useful to expose when running servers
locally).
The "type" of the tag isn't defined because this information isn't yet
exposed to the hgweb templater (it could be in a follow-up) and because
it is questionable whether different types should be exposed at all.
(Should the web interface really be exposing "local" tags?)
We use an object for the outer type instead of Array for a few reasons.
First, it is extensible. If we ever need to throw more global properties
into the output, we can do that without breaking backwards compatibility
(property additions should be backwards compatible). Second, uniformity
in web APIs is nice. Having everything return objects seems much saner than
a mix of array and object. Third, there are security issues with arrays
in older browsers. The JSON web services world almost never uses arrays
as the main type for this reason.
Another possibly controversial part about this patch is how dates are
defined. While JSON has a Date type, it is based on the JavaScript Date
type, which is widely considered a pile of garbage. It is a non-starter
for this reason.
Many of Mercurial's built-in date filters drop seconds resolution. So
that's a non-starter as well, since we want the API to be lossless where
possible. rfc3339date, rfc822date, isodatesec, and date are all lossless.
However, they each require the client to perform string parsing on top of
JSON decoding. While date parsing libraries are pretty ubiquitous, some
languages don't have them out of the box. However, pretty much every
programming language can deal with UNIX timestamps (which are just
integers or floats). So, we choose to use Mercurial's internal date
representation, which in JSON is modeled as float seconds since UNIX
epoch and an integer timezone offset from UTC (keep in mind
JavaScript/JSON models all "Numbers" as double prevision floating point
numbers, so there isn't a difference between ints and floats in JSON).
Many have long wanted hgweb to emit a common machine readable output.
We start the process by defining a stub json template.
Right now, each endpoint returns a stub "not yet implemented" string.
Individual templates will be implemented in subsequent patches.
Basic tests for templates have been included. Coverage isn't perfect,
but it is better than nothing.
There's a "p.changeset-age span" css block in style-monoblue.css with quite a
bit of rules, including position. They were all unused, since there weren't
matching span element inside the p.changeset-age.
The span was removed in 064b658181dd (as it seemed meaningless at the time?)
and since then relative changeset age text looked weird and broken.
"age" class is used for calculating relative changeset age in javascript: all
content of such element is replaced with human-friendly text (e.g.
"yesterday"). So the new span gets the age class.
'<a .../>foo</a>' syntax is incorrect, since the first tag just "tries" to
close itself and then the actual content follows. It doesn't work, either
because web browsers know better than this or because there should be a
whitespace before /: '<a />'. So for the hgweb users the links looked
normal anyway, but now they are correct in code as well.
<p> elements can only contain inline elements, so as soon as browser encounters
a block element (e.g. block <div>) "inside" a <p>, it puts an implicit </p>.
It's better to do this explicitly.
coal style uses every template (except header.tmpl) directly from paper style,
but doesn't use paper/map file. Elements defined in such map files are used in
templates as you would expect. For example, paper/search.tmpl contains
'{searchhint}' and template engine replaces that with the actual hint. But when
coal style reuses paper/search.tmpl, it needs to define searchhint in its map
file as well, or template engine will not find it. So let's copy it from
paper/map to coal/map.
Before this change, if the coal style was selected, the hint for the search
field in page header was present, but it was completely empty. Although the
absence of searchhint in coal/map produced no error.
Pulls the autogenerated line number boxes outside of the padding box
of the main content of .sourcelines, allowing the first tab
to be properly sized and the line numbers to be outside
the main source's margin when text is wrapped.
Elements in map files work slightly different from regular python strings, so
escaping single quotes is not necessary. It is also demonstrated by the very
same lines: '(current diff)'.
I should've made this in 3468fd599ef4, but here we go.
Some templates in paper style use <tbody> elements inside <table> to assign a
class to "body" part of that table (in this case, to make rows striped). The
problem is that the <tbody> is preceded by <tr> element, which browsers
understand as an implicit start of table body, so the following exlicit <tbody>
will actually be "nested", which is not valid.
Since that first <tr> contains table headers, wrapping it in <thead> is both
semantically correct and follows the advertised XHTML 1.1 doctype.
The <p> elements were used to create an empty space between the diffstat link
and the diffstat table, but they don't have any semantic meaning, so it is
better to use css instead.
Default margins for <p> elements can differ depending on the browser, but
usually the margin is 1em (exceptions are IE 6 and 7 with 14pt, which is
comparable). The css rule sets top margin to 1em.
This change is a "better version" of e028c221db4e, where <p> elements were
simply properly closed.
The <p> elements were used to create an empty space between the last menu item
(i.e. "help") and the atom feed icon, but they don't have any semantic meaning,
so it is better to use css instead.
The css rule uses top margin of 10px, which is equal to the top margin of the
menu blocks ("help", "changeset, browse", etc). Previously, with <p> elements,
the margin wasn't set explicitly and was browser-dependent.
This change is a "better version" of e028c221db4e, where <p> elements were
simply properly closed.
