When this "descend" query parameter is present along with "linerange"
parameter, we get revisions following line range in descending order. The
parameter has no effect without "linerange".
When "patch" query parameter is present in requests to filelog view, line ids
in patches diff are no longer unique in the page since several patches are
shown on the same page. We now prefix line id by changeset shortnode when
several patches are displayed in the same page to have unique line ids
overall.
The previous clause for filter out a diff hunk was too restrictive. We need to
consider the following cases (assuming linerange=(lb, ub) and the @s2,l2
hunkrange):
<-(s2)--------(s2+l2)->
<-(lb)---(ub)->
<-(lb)---(ub)->
<-(lb)---(ub)->
previously on the first and last situations were considered.
In test-hgweb-filelog.t, add a couple of lines at the beginning of file "b" so
that the line range we will follow does not start at the beginning of file.
This covers the change in aforementioned diff hunk filter clause.
We now handle a "linerange" URL query parameter to filter filelog using
a logic similar to followlines() revset.
The URL syntax is: log/<rev>/<file>?linerange=<fromline>:<toline>
As a result, filelog entries only consists of revision changing specified
line range.
The linerange information is propagated to "more"/"less" navigation links but
not to numeric navigation links as this would apparently require a dedicated
"revnav" class.
Only update the "paper" template in this patch.
Add support for a "patch" query parameter in filelog web command similar to
--patch option of `hg log` to display the diff of each changeset in the table
of revisions. The diff text is displayed in a dedicated row of the table that
follows the existing one for each entry and spans over all columns. Only
update "paper" template in this patch.
All the hgweb templates include mercurial.js in their header. All
the hgweb templates have the same <script> boilerplate to run
process_dates(). This patch factors that function call into
mercurial.js as part of a DOMContentLoaded event listener.
It was mixing tabs and spaces, and not in a good way.
Indent style of other atom entries seems to be 1 space per level, so let's
apply it here as well.
currently "subscribe to atom feed" link in file log page is as follows.
/atom-log/[revision]/[file]
This is invalid, because we could not get newer commit feed than [revision].
To fix this, atom-log feed url should be the following style.
atom-log/tip/[file]
Let's make paper (and coal, since it borrows so much from paper) templates use
symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes.
Some pages don't have permanent links to current node hash (so it's not very
easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
patches.
Let's make spartan templates use symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes, and
many pages also have permanent link to current node hash (i.e. you can go from
/rev/tip to /rev/<tip hash> without manual url editing), so it's safe to
update navigation.
$TESTDIR is added to the path, so this is superfluous. Also,
inconsistent use of quotes means we might have broken on tests with
paths containing spaces.
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.
Displaying branches, tags and bookmarks is an obviously important feature of
hgweb and should be tested a bit more than not at all, so let's add a branch, a
tag and a bookmark to the test.
With this change it's evident that the default style (paper) doesn't show
bookmarks in filelog. Future patch will fix this.
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.
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 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.
<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.
Before this patch, each log entries in "changelog" and "revisions"
pages of "spartan" style are not aligned by column, because:
- each log entries are separated "<table>" entries, and
- there are no fixed "width" information for each "<th>"/"<td>" entries
This patch aligns entries in "changelog" and "revisions" pages of
"spartan" style by:
- adding 'label' class to '<th>' for 'age' information, and
- setting 'width' of '<th class="label">' with fixed size
'class="age"' is not used for this purpose, because it is also used to
set "bold" font-weight
"16em" seems to be wide enough to show date information fully, when
web browser disables (or doesn't support) javascript.
Adds new web command to the core, ``comparison``, which enables colorful
side-by-side change display, which for some might be much easier to work with
than the standard line diff output. The idea how to implement comes from the
SonicHq extension.
The web interface gets a new link to call the comparison functionality. It lets
users configure the amount of context lines around change blocks, or to show
full files - check help (also in this changeset) for details and defaults. The
setting in hgrc can be overridden by adding ``context=<value>`` to the request
query string. The comparison creates addressable lines, so as to enable sharing
links to specific lines, just as standard diff does.
Incorporates updates to all web related styles.
Known limitations:
* the column diff is done against the first parent, just as the standard diff
* this change allows examining diffs for single files only (as I am not sure if
examining the whole changeset in this way would be helpful)
* syntax highlighting of the output changes is not performed (enabling the
highlight extension has no influence on it)
get-with-headers.py took the http GET parameter as a command line parameter
that had to start with '/'. MSYS on windows will mangle such paths.
Instead of applying a workaround everywhere (such as an extra '/') we let
get-with-headers.py add the mandatory '/'. That is consistent with the
url path handling in the Mercurial url class.
A few tests sent 'GET ?cmd=...' which is invalid. They will now send 'GET
/?cmd=...'.
This will not enable any tests for being run on windows - only remove one
reason they were disabled.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
While Chrome, Firefox, and IE 6+ support the current date format being
passed to Date(), Safari doesn't:
> new Date('Mon Oct 24 13:58:01 2011 +0200')
Invalid Date
However, the rfc822date format--officially supported by
ECMAScript[1]--does work:
> new Date('Mon, 24 Oct 2011 13:58:01 +0200')
Mon Oct 24 2011 04:58:01 GMT-0700 (PDT)
This change replaces all instances of {date|date} in HTML with
{date|rfc822date}. For elements that only have the "age" class,
there's no outward change for users with JavaScript enabled. For
elements with both the "age" and "date" classes, the full date
displayed uses the new format.
Tested in IE 6, Safari 5.1.1, Google Chrome 15, and Firefox 7.0.1.
[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
This allow safe caching of the pages by the browser and still display the right
amount of elapsed time upon page refresh.
If javascript is disabled, absolute time is displayed, leaving it readable.
All the templates have been updated.