Fri, 25 Sep 2015 12:38:20 +0800 gitweb, monoblue: port highlighting linked lines from paper
Anton Shestakov <av6@dwimlabs.net> [Fri, 25 Sep 2015 12:38:20 +0800] rev 26363
gitweb, monoblue: port highlighting linked lines from paper This is adapted from 41c4bdd1d585, fbfe5748ef3e and f3393d458bf5.
Fri, 25 Sep 2015 03:02:38 +0800 gitweb, monoblue: fix vertical align of spans in .sourcelines
Anton Shestakov <av6@dwimlabs.net> [Fri, 25 Sep 2015 03:02:38 +0800] rev 26362
gitweb, monoblue: fix vertical align of spans in .sourcelines Empty lines in file view could produce an inexplicable margin before the next line (most noticeable in browsers on webkit/blink engine). That was making empty lines seem taller than the rest. Instead of using default vertical align, let's set it to 'top'. This issue is actually present in paper, and only recently got into gitweb (2239626369f5) and monoblue (119202d4d7a4). There's a bit more to it in paper, so that will be dealt with in a future patch. Recipe to see live: preferably using a webkit/blink browser, such as chromium, browse a file with empty lines, e.g. https://selenic.com/hg/file/3.5/README#l8 Selecting a block of text that includes empty lines will reveal white "breaks" in the selection. Highlighted line (#l8) also shows such a break below itself.
Fri, 25 Sep 2015 00:54:20 -0400 merge: fix mergestate comment
timeless@mozdev.org [Fri, 25 Sep 2015 00:54:20 -0400] rev 26361
merge: fix mergestate comment
Thu, 24 Sep 2015 17:51:05 -0400 rebase: avoid losing branch commits with --keepbranch (issue4835)
timeless@mozdev.org [Thu, 24 Sep 2015 17:51:05 -0400] rev 26360
rebase: avoid losing branch commits with --keepbranch (issue4835)
Thu, 24 Sep 2015 16:03:26 -0700 lock.release: do not unlink inherited locks
Siddharth Agarwal <sid0@fb.com> [Thu, 24 Sep 2015 16:03:26 -0700] rev 26359
lock.release: do not unlink inherited locks This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. A subprocess unlinking a lock will lead to potential corruption from other concurrent processes.
Thu, 24 Sep 2015 16:00:41 -0700 lock: add a method to reacquire the lock after subprocesses exit
Siddharth Agarwal <sid0@fb.com> [Thu, 24 Sep 2015 16:00:41 -0700] rev 26358
lock: add a method to reacquire the lock after subprocesses exit This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances.
Thu, 24 Sep 2015 10:37:13 -0700 lock: add a method to prepare the lock for inheritance
Siddharth Agarwal <sid0@fb.com> [Thu, 24 Sep 2015 10:37:13 -0700] rev 26357
lock: add a method to prepare the lock for inheritance This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances.
Thu, 24 Sep 2015 15:57:11 -0700 lock: introduce state to keep track of inheritance
Siddharth Agarwal <sid0@fb.com> [Thu, 24 Sep 2015 15:57:11 -0700] rev 26356
lock: introduce state to keep track of inheritance This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In upcoming patches we will refer to this state.
Thu, 24 Sep 2015 10:53:16 -0700 error: add an exception to indicate lock inheritance API contract violations
Siddharth Agarwal <sid0@fb.com> [Thu, 24 Sep 2015 10:53:16 -0700] rev 26355
error: add an exception to indicate lock inheritance API contract violations
Thu, 24 Sep 2015 15:52:11 -0700 clone: check update rev for being True
Sean Farley <sean@farley.io> [Thu, 24 Sep 2015 15:52:11 -0700] rev 26354
clone: check update rev for being True In 30be3aeb5344, there was an attempt to fallback to looking up the update revision assuming it was always a rev but the documentation states: True means update to default rev, anything else is treated as a revision Therefore, we should only fallback to looking up the update rev if it is not True. This bug was found in hg-git and I couldn't think of a test that does this in pure Mercurial since the source repository is checked for the revision as well (and therefore gracefully falls back).
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip