Tue, 22 Aug 2017 12:59:21 -0400 contrib: have import-checker work mostly with native strings for mod names
Augie Fackler <raf@durin42.com> [Tue, 22 Aug 2017 12:59:21 -0400] rev 33890
contrib: have import-checker work mostly with native strings for mod names Module names are a bit awkward to deal with portably otherwise.
Wed, 23 Aug 2017 12:35:03 -0700 bundlerepo: move bundle2 part handling out to a function
Durham Goode <durham@fb.com> [Wed, 23 Aug 2017 12:35:03 -0700] rev 33889
bundlerepo: move bundle2 part handling out to a function This moves the bundle2 part handling for bundlerepo out to a separate function so extensions can participate in bundlerepo setup when using bundle2 bundles. Differential Revision: https://phab.mercurial-scm.org/D290
Wed, 23 Aug 2017 12:35:03 -0700 bundle2: seek part back during iteration
Durham Goode <durham@fb.com> [Wed, 23 Aug 2017 12:35:03 -0700] rev 33888
bundle2: seek part back during iteration Previously, iterparts would yield the part to users, then consume the part. This changed the part after the user was given it and left it at the end, both of which seem unexpected. Let's seek back to the beginning after we've consumed it. I tried not seeking to the end at all, but that seems important for the overall bundle2 consumption. This is used in a future patch to let us move the bundlerepo bundle2-changegroup-part to be handled entirely within the for loop, instead of having to do a seek back to 0 after the entire loop finishes. Differential Revision: https://phab.mercurial-scm.org/D289
Wed, 23 Aug 2017 12:34:56 -0700 bundlerepo: move temp bundle creation to a separate function
Durham Goode <durham@fb.com> [Wed, 23 Aug 2017 12:34:56 -0700] rev 33887
bundlerepo: move temp bundle creation to a separate function A future patch will refactor certain parts of bundlerepo initiatlization such that we need to create temp bundles from another function. Let's move this to another function to support that. Differential Revision: https://phab.mercurial-scm.org/D288
Thu, 17 Aug 2017 13:04:47 -0700 exchange: don't attempt phase exchange if phase-heads was in bundle
Martin von Zweigbergk <martinvonz@google.com> [Thu, 17 Aug 2017 13:04:47 -0700] rev 33886
exchange: don't attempt phase exchange if phase-heads was in bundle The Mercurial core server doesn't yet include phase-heads parts in the bundle, but our Google-internal server wants to do that. Unfortunately, the usual exchange still happens even if phase-heads part is included (including the short-circuited one for old/publishing servers). That means that even if our server (again, the Google-internal one, but also future Mercurial core servers) includes a phase-heads part to indicate that some heads should be drafts, that would still get overwritten by the phase updating that happens after. So let's fix that by marking the phase step done if we receive at least one phase-heads part in the bundle. Differential Revision: https://phab.mercurial-scm.org/D440
Wed, 16 Aug 2017 15:48:48 -0700 pushvars: do not mangle repo state
Jun Wu <quark@fb.com> [Wed, 16 Aug 2017 15:48:48 -0700] rev 33885
pushvars: do not mangle repo state Setting `repo._shellvars` works but is not a clean way to pass the pushvars information from the push command to the exchange operation. Therefore change it to actually pass `pushvars` as a push operation argument instead. This makes third party extension like remotenames easier to support pushvars cleanly. The key value parsing and verification code has been moved to a lower level so it's harder to be bypassed and easier to be used in remotenames which could replace `push` command entirely. Differential Revision: https://phab.mercurial-scm.org/D423
Sun, 27 Aug 2017 13:39:17 -0700 record: fix revert -i for lines without newline (issue5651) stable
Jun Wu <quark@fb.com> [Sun, 27 Aug 2017 13:39:17 -0700] rev 33884
record: fix revert -i for lines without newline (issue5651) This is a regression caused by 66117dae87f9. Code prior to 66117dae87f9 seems to miss the "\ No newline at end of file" line. Differential Revision: https://phab.mercurial-scm.org/D528
Mon, 21 Aug 2017 16:43:37 +0530 morestatus: check whether the conflict message is None before printing
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 21 Aug 2017 16:43:37 +0530] rev 33883
morestatus: check whether the conflict message is None before printing There are cases like bisect when the conflict message can be None. So we make sure that we don't print None in that case. Thanks to Martin for catching this. Differential Revision: https://phab.mercurial-scm.org/D461
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip