- Sep 25, 2019
-
-
Pierre-Yves David authored
Until now, the experimental option `single-head-per-branch` was also refusing closed heads. The logic is now ignoring them by default and a suboption have been added to refuse them too `single-head-per-branch:account-closed-heads`.
-
Pierre-Yves David authored
This is simple and handy. See next changesets for usage.
-
Pierre-Yves David authored
The sentence is now correct.
-
- May 20, 2019
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6873
-
Augie Fackler authored
This is the configuration contributors should use for our C/C++ code. I expect to expand this file as we get more automated formatter oversight. Differential Revision: https://phab.mercurial-scm.org/D6872
-
- Sep 18, 2019
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D6870
-
- Sep 17, 2019
-
-
Kyle Lippincott authored
On some networked filesystems, writes can have delayed finalization/confirmation and write races can occur such that a remote modification will "win" and modifications will be lost. There is no functionality for providing this feedback to userspace programs (in fact, there's not even functionality for providing this information to the Linux kernel...), so these programs may see the files suddenly change. We've noticed that there have been cases where Mercurial has detected something has gone wrong and attempts to abort (rolling back the transaction), which is good. However, when rolling back the transaction, for the append-only files, we attempt to "truncate" the file back to the size it was in before the hg transaction started, but end up *extending* it. This may be harmless, but if this happens to the 00changelog.i file, we get a bunch of nulls on the end of the file and this causes hg to become *really* confused. :) If we detect that some modification of the file outside of this Mercurial process has caused the file to be smaller than the size we are attempting to truncate to, let's just exit and stop trying to clean up the repository - continuing will likely just cause more damage. Differential Revision: https://phab.mercurial-scm.org/D6867
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6866
-
Kyle Lippincott authored
In some situations, we run a custom python launcher that appears to not set up Py_GetArgcArgv correctly. We then proceed to promptly crash when we attempt to dereference NULL. Being able to completely disable setprocname is beneficial in these situations, since we won't even attempt to use it, even if the case that causes the crash is fixed. Right now, if I compile osutil.so with -DSETPROCNAME_USE_NONE, the compilation fails on python3 due to SETPROCNAME_USE_NONE redefinition. I could possibly work around that, but it's likely helpful to have a way of disabling this completely without it being brittle (i.e. if python3 ever gains the ability to perform this operation). Differential Revision: https://phab.mercurial-scm.org/D6865
-
- Sep 22, 2019
-
-
Anton Shestakov authored
Using scmutil.revrange() it's possible to use multiple revsets at the same time, but we're not using that functionality in stack. I thought maybe that function could be used to make stack definition customizable (by combining various parts into one set), but scmutil.revrange() gives the union of all provided revsets, which is not very useful in stack's case (we want "and" between parts, not "or").
-
- Sep 23, 2019
-
-
Yuya Nishihara authored
-
- Sep 20, 2019
-
-
Anton Shestakov authored
Turns out it's not enough to just swap parents, because when we do, there are unexpected bad side effects, such as a tracked file becoming untracked. These side effects need more code to be handled properly, but it's not written yet. Let's back this feature out from stable for now and some day implement it on default instead.
-
- Sep 01, 2019
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D6774
-
Raphaël Gomès authored
This change is a direct consequence of this discussion on the mailing list: https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-August/133574.html The implementations of `HgPath` and `HgPathBuf` are, for the most part, taken directly from `OsStr` and `OsString` respectively from the standard library. What this change does *not* yet do is implement the Windows MBCS to WTF8 conversion, but it lays the basis for a very flexible interface for paths. Differential Revision: https://phab.mercurial-scm.org/D6773
-
- Sep 18, 2019
-
-
Martin von Zweigbergk authored
It seems like it was a mix of what the Python code would see and what was sent over the wire. I've tried to clarify both the type seen in Python and how it's transmitted. Differential Revision: https://phab.mercurial-scm.org/D6871
-
Yuya Nishihara authored
-
Anton Shestakov authored
See a4ca0610c754. potherp1 is a boolean variable that means "pother is ctx.p1", and parents is naturally [ctx.p1, ctx.p2]. pctx is always removed from parents, so if pctx is parents[0], then we end up using parents[1] as pother. To be true to its name, potherp1 should then be True only when pctx is at parents[1].
-
- Sep 17, 2019
-
-
Martin von Zweigbergk authored
The "opts" are already converted to bytes at the beginning of the function. Doing it twice results in a crash, which makes test-uncommit.t fail. The extra call was added recently, in ff1ff2aae132 (uncommit: add support to modify the commit message and date, 2019-09-07). test-uncommit.t passes again after this patch. Differential Revision: https://phab.mercurial-scm.org/D6864
-
Ian Moody authored
So it doesn't die with "TypeError: cannot use a string pattern on a bytes-like object". Differential Revision: https://phab.mercurial-scm.org/D6863
-
Ian Moody authored
This was a regression I introduced in c19d259fd6ad. When the string gets to the memoryview in _tokenize under py3 it'll die. Differential Revision: https://phab.mercurial-scm.org/D6869
-
Ian Moody authored
Skipping can currently only happen with `--no-amend`, so this isn't a usual configuration. Differential Revision: https://phab.mercurial-scm.org/D6868
-
Augie Fackler authored
Most users won't notice a change here because they won't have the fuzzer infra, but by good fortune my workstation has the required bits and keeps leaving the fuzzer binaries around. Differential Revision: https://phab.mercurial-scm.org/D6862
-
Augie Fackler authored
We've seen enough weirdness in CI with flock for remotefilelog that I'm now of the opinion we should just stop using flock() everywhere until someone has a concrete need for the extra performance *and* a way to only use it when safe (even if that's just default-to-off.) Differential Revision: https://phab.mercurial-scm.org/D6861
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6860
-
- Sep 13, 2019
-
-
Martin von Zweigbergk authored
It's been a somewhat common request among our users to have Mercurial automatically pick includes to remove. This patch adds an option for that: `hg tracked --auto-remove-includes`. I'm not sure if this is the right name and semantics for it. Perhaps the feature should also add excludes of large subdirectories even if other files in the include are needed? Narrow clones are experimental, so we can change the name and/or semantics later if necessary. Differential Revision: https://phab.mercurial-scm.org/D6848
-
Martin von Zweigbergk authored
It isn't obvious, but wireprototypes.encodelist() is meant only for binary nodeids. So when we used it for encoding hex nodeids and paths, the encoded result was surprising and hard to read. This patch changes the encoding to make the list of paths a comma-separated list and the list of common nodes to be a encodelist()-encoded list of binary nodeids (so the result is just singly-hexified nodeids). This is clearly a breaking change, but the feature is experimental and we're not aware of anyone running a server using this command yet. Differential Revision: https://phab.mercurial-scm.org/D6851
-
- Sep 11, 2019
-
-
Boris Feld authored
2c74337e6483 reduced the probability of race-conditions when starting background repack and prefetch and we saw the difference in our CI instance with all failures disappearing except one where one call to waitonrepack seems to returns too early. I'm not sure what exactly goes wrong but I realized that while the prefetch operation uses a standard Mercurial lock, the repack operation is using a custom lock based on `fcntl.flock` on available platforms. As `extutil.flock` fallback on traditional Mercurial locks on other platforms and the tests are stable on my laptop, our CI environment and GCC112, I'm sending this patch to standardize the behavior across environments. Differential Revision: https://phab.mercurial-scm.org/D6844
-
- Sep 17, 2019
-
-
Pierre-Yves David authored
The arguments will display some statisting about the distribution of the value we measure.
-
Pierre-Yves David authored
The arguments will display some statistics about the distribution of the value we measure.
-
David Demelier authored
-
- Sep 15, 2019
-
-
Yuya Nishihara authored
If decrease_leak_count() were called unnecessarily, there must be a serious bug. It's better to not silently ignore such cases.
-
- Sep 14, 2019
-
-
Matt Harbison authored
`pwd` prints /tmp/... style paths, not C:\... needed for $TESTTMP to be substituted. In the final test, for whatever reason, Windows was missing EOL in the files and printing: [wdir] changedlines: printf: warning: ignoring excess arguments, starting with 'printf' even though it was trying to run: printf "Line ranges:\n"; printf "2 through 2\n"; I tried wrapping both :command and :linerange in `sh -c "..."`, and while that fixed the missing EOL, it missed the "2 through 2" output. Differential Revision: https://phab.mercurial-scm.org/D6852
-
- Sep 16, 2019
-
-
Gregory Szorc authored
The upstream source distribution from PyPI was extracted. Unwanted files were removed. The clang-format ignore list was updated to reflect the new source of files. test-repo-compengines.t was updated to reflect a change in behavior of the zstd library. The project contains a vendored copy of zstandard 1.4.3. The old version was 1.3.8. This should result in some minor performance wins. # no-check-commit because 3rd party code has different style guidelines Differential Revision: https://phab.mercurial-scm.org/D6858
-
- Sep 15, 2019
-
-
Matt Harbison authored
This comes from the evolve extension's version of uncommit. The logic was already in place, and appears to be the last of the trivial things that can be enabled. Should these note options (including on amend) be marked advanced to keep the help text clutter level down? Differential Revision: https://phab.mercurial-scm.org/D6857
-
Matt Harbison authored
This comes from the evolve extension's version of amend. The logic was already in place, and appears to be the last of the trivial things that can be enabled. Differential Revision: https://phab.mercurial-scm.org/D6856
-
Matt Harbison authored
This comes from the evolve extension's version of amend. The logic was already in place. Differential Revision: https://phab.mercurial-scm.org/D6855
-
- Sep 14, 2019
-
-
Matt Harbison authored
This comes from the evolve function. I'm not sure why this check was missing in core, since it was present when the length check was added to evolve. I didn't flag this as BC because 530b7361e3a9 mentioned this argument wasn't added to the release notes due to no display capability, and that hasn't changed AFAIK. Differential Revision: https://phab.mercurial-scm.org/D6854
-
Matt Harbison authored
This is also from the evolve extension's version of amend. A side effect of this refactoring is for uncommit to support `rewrite.update-timestamp`. Differential Revision: https://phab.mercurial-scm.org/D6853
-
- Sep 11, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6850
-
- Sep 13, 2019
-
-
Martin von Zweigbergk authored
I'm about to add another test that depends on this config. Differential Revision: https://phab.mercurial-scm.org/D6849
-