Mon, 09 May 2016 21:13:50 -0400 httpclient: update to upstream revision 2995635573d2
Augie Fackler <augie@google.com> [Mon, 09 May 2016 21:13:50 -0400] rev 29131
httpclient: update to upstream revision 2995635573d2 This is mostly Python 3 compat work thanks to timeless.
Fri, 06 May 2016 19:52:21 +0800 crecord: call prevsibling() and nextsibling() directly
Anton Shestakov <av6@dwimlabs.net> [Fri, 06 May 2016 19:52:21 +0800] rev 29130
crecord: call prevsibling() and nextsibling() directly The 3 classes for items used in crecord (uiheader, uihunk, uihunkline) all have prevsibling() and nextsibling() methods. The two methods are used to get the previous/next item of the same type of the same parent element as the current one: when `a` is a uihunkline instance, a.nextsibling() returns the next line in this hunk (or None, if `a` is the last line). There are also two similar methods: previtem() and nextitem(). When called with constrainlevel=True (the default) they simply returned the result of prevsibling()/nextsibling(). Only when called with constrainlevel=False they did something different: they returned previous/next item regardless of its type (so if `a` is the last line in a hunk, a.nextitem(constrainlevel=False) could return the next hunk or the next file -- something that is not a line). Let's simplify this logic and make code call -sibling() methods when only siblings are needed and -item() methods when any item would do, and then remove the constrainlevel argument from previtem() and nextitem().
Thu, 28 Apr 2016 10:37:47 -0400 dispatch: add fail-* family of hooks
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 28 Apr 2016 10:37:47 -0400] rev 29129
dispatch: add fail-* family of hooks The post-* family of hooks will not run in case a command fails (i.e. raises an exception). This makes it inconvenient to hook into events such as doing something in case of a failed push. We catch all exceptions to run the failure hook. I am not sure if this is too aggressive, but tests apparently pass.
Fri, 06 May 2016 22:21:32 +0530 py3: make hgext/rebase.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 22:21:32 +0530] rev 29128
py3: make hgext/rebase.py use absolute_import
Fri, 06 May 2016 21:54:31 +0530 py3: make hgext/mq.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 21:54:31 +0530] rev 29127
py3: make hgext/mq.py use absolute_import
Fri, 06 May 2016 21:52:26 +0530 py3: make hgext/hisedit.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 21:52:26 +0530] rev 29126
py3: make hgext/hisedit.py use absolute_import
Fri, 06 May 2016 21:50:40 +0530 py3: make hgext/hgk.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 21:50:40 +0530] rev 29125
py3: make hgext/hgk.py use absolute_import
Fri, 06 May 2016 21:46:17 +0530 py3: make hgext/gpg.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 21:46:17 +0530] rev 29124
py3: make hgext/gpg.py use absolute_import
Fri, 06 May 2016 21:48:17 +0530 py3: make hgext/graphlog.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 May 2016 21:48:17 +0530] rev 29123
py3: make hgext/graphlog.py use absolute_import
Sat, 07 May 2016 19:59:30 +0200 import-checker: recognize relative imports from parents of current package
liscju <piotr.listkiewicz@gmail.com> [Sat, 07 May 2016 19:59:30 +0200] rev 29122
import-checker: recognize relative imports from parents of current package So far fromlocal recognizes relative imports of the form: from . import D from .. import E It wasn't prepared for recognizing relative imports like: from ..F import G The bug was not found so far because all relative imports starting from the parent was in the list of allowsymbolicimports like: from ..i18n import from ..node import
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip