Fri, 05 Jan 2018 19:16:08 +0800 gitweb: make actual changeset entries have backgrounds on /graph
Anton Shestakov <av6@dwimlabs.net> [Fri, 05 Jan 2018 19:16:08 +0800] rev 35531
gitweb: make actual changeset entries have backgrounds on /graph This patch removes a separate container for backgrounds only and puts backgrounds on changeset elements themselves. This makes it so that JS code doesn't need to create background elements separately anymore. There's a bit of manipulating positions of elements: every changeset entry has a "fg" element that gets a higher z-index than <canvas> element. This prioritizes text information, so that even if it somehow gets close to the graph drawn on <canvas> (which has z-index of 5), it'll still be on top of it. This can happen if commit message has a long first line and browser window is narrow, for example.
Fri, 05 Jan 2018 19:08:00 +0800 monoblue: make actual changeset entries have backgrounds on /graph
Anton Shestakov <av6@dwimlabs.net> [Fri, 05 Jan 2018 19:08:00 +0800] rev 35530
monoblue: make actual changeset entries have backgrounds on /graph This patch removes a separate container for backgrounds only and puts backgrounds on changeset elements themselves. This makes it so that JS code doesn't need to create background elements separately anymore. There's a bit of manipulating positions of elements: every changeset entry has a "fg" element that gets a higher z-index than <canvas> element. This prioritizes text information, so that even if it somehow gets close to the graph drawn on <canvas> (which has z-index of 5), it'll still be on top of it. This can happen if commit message has a long first line and browser window is narrow, for example. 'parity' is added to each entry because there's no stripes2 class in monoblue, only in paper.
Fri, 05 Jan 2018 18:46:06 +0800 paper: make actual changeset entries have backgrounds on /graph
Anton Shestakov <av6@dwimlabs.net> [Fri, 05 Jan 2018 18:46:06 +0800] rev 35529
paper: make actual changeset entries have backgrounds on /graph This patch removes a separate container for backgrounds only and puts backgrounds on changeset elements themselves. This makes it so that JS code doesn't need to create background elements separately anymore. There's a bit of manipulating positions of elements: every changeset entry has a "fg" element that gets a higher z-index than <canvas> element. This prioritizes text information, so that even if it somehow gets close to the graph drawn on <canvas> (which has z-index of 5), it'll still be on top of it. This can happen if commit message has a long first line and browser window is narrow, for example.
Thu, 04 Jan 2018 12:34:40 +0100 crecord: fallback to color = no when curses.use_default_colors() fails
Elmar Bartel <elb_hg@leo.org> [Thu, 04 Jan 2018 12:34:40 +0100] rev 35528
crecord: fallback to color = no when curses.use_default_colors() fails Even when python was setup/compiled with curses, curses.use_default_colors() may raise a curses exception when the TERM environment variable specifies a value where no propper color configuration is possible. This patch falls back to non-color mode to let the user continue instead of failing with an unhandled exception.
Thu, 04 Jan 2018 12:12:07 +0100 crecord: honor "ui.color = no" config option
Elmar Bartel <elb_hg@leo.org> [Thu, 04 Jan 2018 12:12:07 +0100] rev 35527
crecord: honor "ui.color = no" config option The current implementation of crecord ignores the ui.color setting. This patch checks the ui.color config option and does the curses setup without colors when the option is set to a falsy value. For other (or missing) setting of ui.color, curses setup is done as before and uses colors.
Tue, 02 Jan 2018 21:46:57 -0500 lfs: use the local store method for opening a blob
Matt Harbison <matt_harbison@yahoo.com> [Tue, 02 Jan 2018 21:46:57 -0500] rev 35526
lfs: use the local store method for opening a blob I noticed that when I cloned without updating and then turned around and pushed that clone to an lfs server, it was only trying to find the blob in the local store. Writes to the dummyremote (file based store) use local.read(), which looks at both the usercache and local store.
Tue, 02 Jan 2018 21:18:30 -0500 lfs: add a local store method for opening a blob
Matt Harbison <matt_harbison@yahoo.com> [Tue, 02 Jan 2018 21:18:30 -0500] rev 35525
lfs: add a local store method for opening a blob The has() and read() methods already dynamically switch between the usercache and local store. This should generally be preferred to directly accessing the vfs instances outside of the store. The file is now explicitly opened in binary mode for clarity. (It was also being opened in binary mode before, but only because vfs.__call__() appends 'b' if needed when not opening with 'text=True'.)
Fri, 05 Jan 2018 17:23:55 +0530 hgdemandimport: use correct hyperlink to python-bug in comments (issue5765)
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 05 Jan 2018 17:23:55 +0530] rev 35524
hgdemandimport: use correct hyperlink to python-bug in comments (issue5765) Differential Revision: https://phab.mercurial-scm.org/D1810
Wed, 03 Jan 2018 10:37:49 +0800 monoblue: adjust font size of graph entries
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jan 2018 10:37:49 +0800] rev 35523
monoblue: adjust font size of graph entries /shortlog uses 1.1em font for changesets, so it makes sense to use the same size on /graph too. In practice, 1.2em is 14.784px, and 1.1em is 13.552px.
Wed, 03 Jan 2018 09:41:01 +0800 hgweb: make .info a block element by default
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jan 2018 09:41:01 +0800] rev 35522
hgweb: make .info a block element by default Using a <div> instead of a <span> with "display: block" makes more sense. While at it, let's adjust top margin in monoblue so that text in .info doesn't overlap changeset "tags" elements (they are quite large in monoblue).
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip