Wed, 21 Nov 2018 21:40:16 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Wed, 21 Nov 2018 21:40:16 +0900] rev 40715
merge with stable
Mon, 19 Nov 2018 21:12:13 +0300 py3: use node.hex(m.digest()) instead of m.hexdigest()
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 19 Nov 2018 21:12:13 +0300] rev 40714
py3: use node.hex(m.digest()) instead of m.hexdigest() hashlib.sha1.hexdigest() returns str on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5287
Sun, 18 Nov 2018 02:40:47 +0100 tests: add Balto configuration file
Boris Feld <boris.feld@octobus.net> [Sun, 18 Nov 2018 02:40:47 +0100] rev 40713
tests: add Balto configuration file I have been developing a Mercurial test runner plugin for being able to run Mercurial tests with Balto (https://bitbucket.org/lothiraldan/balto/src/default/). Balto requires a configuration file so let's include it, I have added the required information in the configuration file as comments. I hope Balto would be an helpful tool for other people than me. Differential Revision: https://phab.mercurial-scm.org/D5283
Mon, 19 Nov 2018 13:40:03 -0500 tests: make test-alias.t pass with re2
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 19 Nov 2018 13:40:03 -0500] rev 40712
tests: make test-alias.t pass with re2 Locally, these "non-ASCII character in alias" errors don't show up, though I get them when the alias is defined at the command line rather than in an hgrc. The brokenness comes from the fact that hgrcs are parsed with regexes, and re/re2 differ in this way: $ python -c 'import re; print(re.compile("(.*)").match("aaa\xc0bbbb").groups())' ('aaa\xc0bbbb',) $ python -c 'import re2; print(re2.compile("(.*)").match("aaa\xc0bbbb").groups())' ('aaa',) Apparently re2 stops when it encounters invalid utf8 (which I suppose makes sense given that '.' matches what appears to be a codepoint rather than a byte). This is presumably a bug in hg, but not very important, so just change the test to stick to valid utf8. Differential Revision: https://phab.mercurial-scm.org/D5288
Mon, 19 Nov 2018 23:08:09 -0800 context: remove seemingly impossible code branch
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Nov 2018 23:08:09 -0800] rev 40711
context: remove seemingly impossible code branch I'm not a Python expert, but I can't think of a way that the following branch can ever be hit: def _changeid(self): if r'_changeid' in self.__dict__: return self._changeid It seems to me that if that condition is true, then this function would not have been called. The only exception I can think of is if a reference to the function had been stored beforehand, something like this: c = fctx.__dict__['_changeid'] fctx._changeid c() But that seems like very unlikely code to exist. The condition was added in 921b64e1f7b9 (filecontext: use 'is not None' to check for filelog existence, 2013-05-01) as a "bonus" change (in addition to what the patch was actually about) Differential Revision: https://phab.mercurial-scm.org/D5289
Mon, 19 Nov 2018 21:11:08 +0300 py3: use pycompat.byteskwargs() to covert keys of kwargs to bytes
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 19 Nov 2018 21:11:08 +0300] rev 40710
py3: use pycompat.byteskwargs() to covert keys of kwargs to bytes Differential Revision: https://phab.mercurial-scm.org/D5286
Mon, 19 Nov 2018 20:30:07 +0300 py3: use '%d' for integers instead of '%s'
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 19 Nov 2018 20:30:07 +0300] rev 40709
py3: use '%d' for integers instead of '%s' Differential Revision: https://phab.mercurial-scm.org/D5285
Mon, 19 Nov 2018 19:57:11 +0300 py3: add 9 new passing tests caught by buildbot
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 19 Nov 2018 19:57:11 +0300] rev 40708
py3: add 9 new passing tests caught by buildbot Differential Revision: https://phab.mercurial-scm.org/D5284
Fri, 09 Nov 2018 13:57:13 +0800 branch: allow changing branch of merge commits with --rev
Anton Shestakov <av6@dwimlabs.net> [Fri, 09 Nov 2018 13:57:13 +0800] rev 40707
branch: allow changing branch of merge commits with --rev Tests show that changing branch of merge commits works fine with evolution and without, so let's allow it. Other safeguards should prevent users from shooting themselves in the foot.
Thu, 15 Nov 2018 22:28:38 -0500 lfs: ensure that the return of urlopener.open() is closed
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 22:28:38 -0500] rev 40706
lfs: ensure that the return of urlopener.open() is closed No problem observed, just an oversight noticed while reading documentation.
Thu, 15 Nov 2018 11:16:42 -0800 changegroup: avoid instantiating storage if we are not using it
Kyle Lippincott <spectral@google.com> [Thu, 15 Nov 2018 11:16:42 -0800] rev 40705
changegroup: avoid instantiating storage if we are not using it Differential Revision: https://phab.mercurial-scm.org/D5280
Fri, 16 Nov 2018 17:56:36 -0500 http: allow 'auth.prefix' to have a username consistent with the URI
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Nov 2018 17:56:36 -0500] rev 40704
http: allow 'auth.prefix' to have a username consistent with the URI It may be a little weird to put a username in the prefix, but the documentation doesn't disallow it, and silently disallowing it has caused confusion[1]. The username must match what is passed in (which seems to be from the URI via a circuitous route), as well as 'auth.username' if it was specified. I thought about printing a warning for a mismatch, but we already don't print a warning if the 'auth.username' and URI username don't match. This change allows the first and second last new test cases to work as expected. It looks like this would have been a problem since at least 0593e8f81c71. [1] https://www.mercurial-scm.org/pipermail/mercurial/2018-November/051069.html
Thu, 15 Nov 2018 18:14:57 -0500 lfs: make the exception messages consistent
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 18:14:57 -0500] rev 40703
lfs: make the exception messages consistent I don't love that it repeats 'HTTP Error' in an already long message, but I doubt that we should assume that it will always say that on the original exception message.
Thu, 15 Nov 2018 18:08:29 -0500 lfs: handle URLErrors to add additional information
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 18:08:29 -0500] rev 40702
lfs: handle URLErrors to add additional information Sometimes the blob server is hit first (e.g. on push), and sometimes it's hit last (e.g. pull). Throw in depth first subrepo operations, and things quickly get insane. It wasn't even mentioning LFS, so just saying "connection refused" can be confusing- especially if the blob server is a secondary server and connecting to the repo server works. The exception handler for the transfer handler will print the full path to the blob, but that seems fine given that it might be necessary to debug a second server. (We don't yet support a standalone blob server, so the handler for the Batch API will cover 99.9% of the current problems. But it might as well be handled now while I'm thinking about it.) The function for translating to a message was mostly borrowed from scmutil.catchall().
Thu, 15 Nov 2018 17:58:59 -0500 lfs: improve the hints for common errors in the Batch API
Matt Harbison <matt_harbison@yahoo.com> [Thu, 15 Nov 2018 17:58:59 -0500] rev 40701
lfs: improve the hints for common errors in the Batch API The previous message was too debug-ish and less action oriented than a hint should be. The remaining errors that aren't handled are more along the lines of programming errors (not using POST, bad accept type, etc), so I'm not bothering with that. The friendly errors purposely use `self.baseurl` instead of the full Batch API endpoint because I'd expect some copy/paste/modify on the part of the user here, and it would be more confusing if '/objects/batch' magically appeared, but shouldn't be used in the config setting. It still seems like the right thing for debugging in the catchall case.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip