Sat, 24 Feb 2018 19:56:59 -0500 lfs: add the 'Content-Type' header called out in the file transfer spec
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Feb 2018 19:56:59 -0500] rev 37243
lfs: add the 'Content-Type' header called out in the file transfer spec https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads
Sun, 25 Feb 2018 23:44:02 -0500 lfs: improve the client message when the server signals an object error
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Feb 2018 23:44:02 -0500] rev 37242
lfs: improve the client message when the server signals an object error Two things here. First, the previous message included a snippet of JSON, which tends to be long (and in the case of lfs-test-server, has no error message). Instead, give a concise message where possible, and leave the JSON to a debug output. Second, the server can signal issues other than a missing individual file. This change shows a corrupt file, but I'm debating letting the corrupt file get downloaded, because 1) the error code doesn't really fit, and 2) having it locally makes forensics easier. Maybe need a config knob for that.
Sat, 31 Mar 2018 15:54:26 -0400 check-code: tighten the check for `ls -R`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 15:54:26 -0400] rev 37241
check-code: tighten the check for `ls -R` Otherwise, this was flagging `... lfs.serve=False -R server ...` in the tests.
Sat, 31 Mar 2018 16:41:17 +0530 infinitepush: add tests for `hg pull -r <rev>`
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 16:41:17 +0530] rev 37240
infinitepush: add tests for `hg pull -r <rev>` This patch adds test for `hg pull -r <rev>` when the infinitepush extension is not present on the client side and the server by defaults pushes all the incoming push to bundlestore. As the tests show, if a the changeset was applied to the server, that can be pulled, but if a changeset is in the bundlestore we cannot pull that yet. We should support that. Differential Revision: https://phab.mercurial-scm.org/D2998
Sat, 31 Mar 2018 14:56:57 +0530 infinitepush: use bundleoperation.source instead of hacking on tr
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:56:57 +0530] rev 37239
infinitepush: use bundleoperation.source instead of hacking on tr Previous patches added a soutce attribute to bundle2.bundleoperation class which stores the command which leads to current bundleoperation. Let's use that to decide whether a processing a `hg unbundle` or not instead of hacking on transaction. Differential Revision: https://phab.mercurial-scm.org/D2997
Sat, 31 Mar 2018 14:54:12 +0530 bundle2: make source a mandatory argument for bundle2.applybundle() (API)
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:54:12 +0530] rev 37238
bundle2: make source a mandatory argument for bundle2.applybundle() (API) Currently all the callers in the core pass the source argument, making it mandatory will help us storing right source value in bundleoperation() class. Differential Revision: https://phab.mercurial-scm.org/D2996
Sat, 31 Mar 2018 14:51:34 +0530 bundleoperation: pass the source argument from all the users
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:51:34 +0530] rev 37237
bundleoperation: pass the source argument from all the users We now have a source attribute to the bundle2.bundleoperation class which stores the operation which leads to the current bundling/unbundling. Let's make sure we pass source argument from all the users of the command. Differential Revision: https://phab.mercurial-scm.org/D2995
Sat, 31 Mar 2018 14:49:16 +0530 bunlde2: add 'source' as an optional argument to processbundle()
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:49:16 +0530] rev 37236
bunlde2: add 'source' as an optional argument to processbundle() This will help us to pass the source variable to bundleoperation class. Differential Revision: https://phab.mercurial-scm.org/D2994
Sat, 31 Mar 2018 14:47:43 +0530 bundle2: add 'source' atrribute to bundleoperation class
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:47:43 +0530] rev 37235
bundle2: add 'source' atrribute to bundleoperation class This will help us in easily finding out which command leads to the current operation without hacking on the transaction. Differential Revision: https://phab.mercurial-scm.org/D2993
Sat, 31 Mar 2018 10:13:05 -0700 infinitepush: don't force ipv6 while connecting to mysql server
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 10:13:05 -0700] rev 37234
infinitepush: don't force ipv6 while connecting to mysql server Facebook internally enforces this but looks like we can't force this for pur users. Differential Revision: https://phab.mercurial-scm.org/D2992
Sat, 31 Mar 2018 14:33:37 +0530 infinitepush: drop the default value of config options which are registered
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:33:37 +0530] rev 37233
infinitepush: drop the default value of config options which are registered Differential Revision: https://phab.mercurial-scm.org/D2991
Sat, 31 Mar 2018 14:31:29 +0530 infinitepush: replace `remotenames.hoist` with `remotenames.hoistedpeer`
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:31:29 +0530] rev 37232
infinitepush: replace `remotenames.hoist` with `remotenames.hoistedpeer` The remotenames.hoist config option was renamed to remotenames.hoistedpeer while moving to core as an extension. Let's start using the config option provided by the in-core extension. Differential Revision: https://phab.mercurial-scm.org/D2990
Sun, 18 Mar 2018 16:57:07 +0900 templater: drop global exception catcher from runfilter() (API)
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:57:07 +0900] rev 37231
templater: drop global exception catcher from runfilter() (API) Now all built-in template filters declare input data types or handle type errors by themselves. .. api:: Template filters should declare input data type and/or catch AttributeError, ValueError, TypeError, etc. as needed. See the doc of ``registrar.templatefilters`` for details.
Sun, 18 Mar 2018 16:53:08 +0900 templatefilters: raise ProgrammingError if unencodable type passed to json()
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:53:08 +0900] rev 37230
templatefilters: raise ProgrammingError if unencodable type passed to json() This shouldn't happen for any template data types (though I know it does because of some templater bugs.) Let's clarify it is a bug.
Sun, 18 Mar 2018 16:47:44 +0900 templatefilters: handle TypeError by count()
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:47:44 +0900] rev 37229
templatefilters: handle TypeError by count() Prepares for removing the weird exception catcher from runfilter().
Sun, 18 Mar 2018 17:02:39 +0900 keyword: declare input type of date filters as date
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 17:02:39 +0900] rev 37228
keyword: declare input type of date filters as date Dropped redundant dateutil.parsedate(), which is now handled by the templater.
Sun, 18 Mar 2018 16:12:44 +0900 templatefilters: declare input type as date where appropriate
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:12:44 +0900] rev 37227
templatefilters: declare input type as date where appropriate I'm not sure if the templateutil.date type can be a thing. Currently it's just a constant.
Tue, 20 Mar 2018 22:57:36 +0900 templater: attach hint to input-type error of runfilter()
Yuya Nishihara <yuya@tcha.org> [Tue, 20 Mar 2018 22:57:36 +0900] rev 37226
templater: attach hint to input-type error of runfilter() Tests will be added by the next patch.
Sun, 18 Mar 2018 15:58:22 +0900 templatefuncs: use evaldate() where seems appropriate
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:58:22 +0900] rev 37225
templatefuncs: use evaldate() where seems appropriate This means date("today") is allowed. Also fixes evaldate() to forcibly use the custom error message if specified.
Sun, 18 Mar 2018 15:55:31 +0900 templater: factor out function that parses argument as date tuple
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:55:31 +0900] rev 37224
templater: factor out function that parses argument as date tuple
Sun, 18 Mar 2018 15:42:28 +0900 templatefilters: declare input type as bytes where appropriate
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:42:28 +0900] rev 37223
templatefilters: declare input type as bytes where appropriate Some test outputs changed since input is now coerced to a byte string. I think that's okay. Maybe {date} should have some readable representation?
Sun, 18 Mar 2018 15:14:58 +0900 templatefilters: allow declaration of input data type
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:14:58 +0900] rev 37222
templatefilters: allow declaration of input data type Currently filters take an unwrapped value, which should have no hybrid magic but actually it does because stringify() relies on it. The 'intype' allows us to pre-process the magic by .e.g. evalstring() keeping filter functions as simple as they are now. stringify() is ported as an example. More follow.
Mon, 19 Mar 2018 20:39:06 +0900 hgweb: use registrar to declare "websub" template filter
Yuya Nishihara <yuya@tcha.org> [Mon, 19 Mar 2018 20:39:06 +0900] rev 37221
hgweb: use registrar to declare "websub" template filter Prepares for adding 'intype' attribute.
Sun, 25 Mar 2018 12:15:33 +0900 procutil: redirect ui.fout to stderr while stdio is protected
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Mar 2018 12:15:33 +0900] rev 37220
procutil: redirect ui.fout to stderr while stdio is protected The new behavior seems slightly nicer as we can at least read the output. And this is similar to what the sshserver is doing, so we can probably reuse protectstdio() instead of the weird hook.redirect(True) hack.
Sun, 25 Mar 2018 12:07:18 +0900 procutil: unroll uin/uout loop in protectstdio()
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Mar 2018 12:07:18 +0900] rev 37219
procutil: unroll uin/uout loop in protectstdio() I'll change uout to be redirected to stderr.
Fri, 30 Mar 2018 22:46:22 -0700 context: drop support for changeid of type long (API?)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Mar 2018 22:46:22 -0700] rev 37218
context: drop support for changeid of type long (API?) I don't see a reason to support type long. It's pretty much the same type as int. There was some discussion about it on the mailing list around the time of ff2f90503d64 (context: work around `long` not existing on Python 3, 2017-03-11), but I couldn't find a good reason to keep it. There was some mention of hgtk doing "repo[long(rev)]", but that was in 2012. Differential Revision: https://phab.mercurial-scm.org/D2989
Sat, 31 Mar 2018 00:02:31 -0400 lfs: drop a duplicate blob verification method
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 00:02:31 -0400] rev 37217
lfs: drop a duplicate blob verification method
Fri, 30 Mar 2018 23:32:06 -0400 server: minor code cleanup
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Mar 2018 23:32:06 -0400] rev 37216
server: minor code cleanup Suggested by Yuya after 77f9e95fe3c4, this is mostly using named values for stdio descriptors. The lockfile is also opened in binary mode when reading back content from the child.
Fri, 30 Mar 2018 23:21:46 -0400 server: refactor 'daemon_postexec' instructions into a dictionary
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Mar 2018 23:21:46 -0400] rev 37215
server: refactor 'daemon_postexec' instructions into a dictionary
Wed, 28 Mar 2018 13:37:19 -0700 cbor: import CBORDecoder and CBOREncoder
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 13:37:19 -0700] rev 37214
cbor: import CBORDecoder and CBOREncoder And format the imports so it is cleaner. Differential Revision: https://phab.mercurial-scm.org/D2978
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip