Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Apr 2017 16:23:41 +0200] rev 31939
hgweb: handle a "descend" query parameter in filelog command
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".
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 16 Jan 2017 09:24:47 +0100] rev 31938
revset: add a 'descend' argument to followlines to return descendants
This is useful to follow changes in a block of lines forward in the history
(for instance, when one wants to find out how a function evolved from a point
in history).
We added a 'descend' parameter to followlines(), which defaults to False. If
True, followlines() returns descendants of startrev.
Because context.blockdescendants() does not follow renames, these are not
followed by the revset either, so history will end when a rename occurs (as
can be seen in tests).
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Apr 2017 15:11:36 +0200] rev 31937
context: add a blockdescendants function
This is symmetrical with blockancestors() and yields descendants of a filectx
with changes in the given line range. The noticeable difference is that the
algorithm does not follow renames (probably because filelog.descendants() does
not), so we are missing branches with renames.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 09 Mar 2017 22:40:52 -0800] rev 31936
url: support auth.cookiesfile for adding cookies to HTTP requests
Mercurial can't currently send cookies as part of HTTP requests.
Some authentication systems use cookies. So, it seems like adding
support for sending cookies seems like a useful feature.
This patch implements support for reading cookies from a file
and automatically sending them as part of the request. We rely
on the "cookiejar" Python module to do the heavy lifting of
parsing cookies files. We currently only support the Mozilla
(really Netscape-era) cookie format. There is another format
supported by cookielib and we may want to consider using that,
especially since the Netscape cookie parser can't parse ports.
It wasn't immediately obvious to me what the format of the other
parser is, so I didn't know how to test it. I /think/ it might
be literal "Cookie" header values, but I'm not sure. If it is
more robust than the Netscape format, we may want to just
support it.