Sun, 18 Jun 2017 00:11:48 +0900 dagop: compute depth in revancestors() generator
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 00:11:48 +0900] rev 33001
dagop: compute depth in revancestors() generator Surprisingly, this makes revset benchmark slightly faster. I don't know why, but it appears that wrapping -inputrev by tuple is the key. So I decided to just enable depth computation by default. # reverse(ancestors(tip)) using hg repo 1) 0.081051 2) 0.075408
Sun, 18 Jun 2017 08:59:09 +0900 dagop: just compare with the last value to deduplicate input of revancestors()
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 08:59:09 +0900] rev 33000
dagop: just compare with the last value to deduplicate input of revancestors() Since we're using a max heap, the current rev should be a duplicate only if it equals to the previous one. We don't have to maintain the whole seen set. # reverse(ancestors(tip)) using hg repo 0) 0.086420 1) 0.081051
Sun, 18 Jun 2017 17:22:57 +0900 dagop: bulk rename variables in revancestors() generator
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 17:22:57 +0900] rev 32999
dagop: bulk rename variables in revancestors() generator - h -> pendingheap: "h" seems too short for variable of long lifetime - current -> currev: future patches will add current "depth" variable - parent -> prev or pctx: short lifetime, follows common naming rules
Sun, 18 Jun 2017 17:16:02 +0900 dagop: comment why revancestors() doesn't heapify input revs at once
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 17:16:02 +0900] rev 32998
dagop: comment why revancestors() doesn't heapify input revs at once I wondered why we're doing this complicated stuff without noticing the input revs may be iterated lazily in descending order. c1f666e27345 showed why.
Sat, 17 Jun 2017 22:33:23 +0900 dagop: unnest inner generator of revancestors()
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 22:33:23 +0900] rev 32997
dagop: unnest inner generator of revancestors() This just moves iterate() to module-level function.
Wed, 21 Jun 2017 17:17:17 +0200 hgweb: plug followlines action in annotate view
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:17:17 +0200] rev 32996
hgweb: plug followlines action in annotate view Add the followlines.js script and corresponding parameters as data attribute on <tbody class="sourcelines"> element. Extend CSS rules so that they also match the DOM structure of annotate view. As previously, only address paper and gitweb styles (other styles do not have followlines at all).
Wed, 21 Jun 2017 17:07:51 +0200 hgweb: parameterize the tag name of elements holding followlines selection
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:07:51 +0200] rev 32995
hgweb: parameterize the tag name of elements holding followlines selection While plugging followlines.js into "annotate" view, we'll need to walk a different DOM structure from that of "filerevision" view. In particular, the selectable source line element is a <tr> in annotate view (in contrast with a <span> in filerevision view). So make this tag name a parameter of followlines.js script by passing its value as a "selectabletag" data attribute of <pre class="sourcelines"> element. As <pre class="sourcelines"> tags are getting quite long in templates, rewrite them on several lines.
Wed, 21 Jun 2017 17:02:21 +0200 gitweb: wrap table rows of annotate view into a <tbody> element
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:02:21 +0200] rev 32994
gitweb: wrap table rows of annotate view into a <tbody> element We will use this element to hook data attribute for the followlines.js script to be plugged in annotate view. Also this gets symmetrical with paper style which already has a <tbody> element.
Thu, 22 Jun 2017 11:16:29 +0200 tests: update regex check for fetch error in test-clonebundles.t
Denis Laxalde <denis@laxalde.org> [Thu, 22 Jun 2017 11:16:29 +0200] rev 32993
tests: update regex check for fetch error in test-clonebundles.t On some systems, e.g. Docker container, the actual error may be: error fetching bundle: [Errno 99] Cannot assign requested address Update the regex to handle this case.
Tue, 20 Jun 2017 20:53:29 -0700 hgweb: use separate CSS class for navigation links in footer
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 20 Jun 2017 20:53:29 -0700] rev 32992
hgweb: use separate CSS class for navigation links in footer 2d93d2159e30 changed the styling of the "page_nav" CSS class to use flexbox to separate elements within the <div>. I didn't realize that this class was used outside of the links in the header. So this resulted in incorrectly formatting links in the footer of various pages. Fix that by introducing a new CSS class that preserves the old CSS behavior.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip