- Sep 06, 2019
-
-
Pierre-Yves David authored
One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6820
-
Pierre-Yves David authored
One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6819
-
Pierre-Yves David authored
One more step towards removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6818
-
Pierre-Yves David authored
This is the first step toward removing the flag processing mixin. Differential Revision: https://phab.mercurial-scm.org/D6817
-
- Sep 03, 2019
-
-
Pierre-Yves David authored
If we want some flag processors to be able to store sidedata it needs to be actually fed that data. Differential Revision: https://phab.mercurial-scm.org/D6816
-
Pierre-Yves David authored
To read sidedata using flagprocessors, we need flag processors to store them. So we pass this information to the flag processing layer. Differential Revision: https://phab.mercurial-scm.org/D6815
-
Pierre-Yves David authored
If we want to eventually store sidedata we need to be able to pass them along. Differential Revision: https://phab.mercurial-scm.org/D6814
-
Pierre-Yves David authored
This makes it possible for flag processors to -read- flag data. Differential Revision: https://phab.mercurial-scm.org/D6813
-
Pierre-Yves David authored
This function input and return are becoming stranger and stranger bnut I don't have a good plan to make is saner without problematic code duplication, so it will be this way to now. Differential Revision: https://phab.mercurial-scm.org/D6812
-
Pierre-Yves David authored
Right now, flag processors does not return sidedata, by they will. So, we prepare the caller to receive it. Differential Revision: https://phab.mercurial-scm.org/D6811
-
Pierre-Yves David authored
So far things, seems logical. Differential Revision: https://phab.mercurial-scm.org/D6810
-
Pierre-Yves David authored
Nothing extra any side data yet. However, it will happens in the future. So we better prepare the callers of the `_revisiondata` to deal with it. Differential Revision: https://phab.mercurial-scm.org/D6809
-
Pierre-Yves David authored
The method give access to extra information related to the revision. Such data will not be part of the hash be strongly related to the revision. Having them stored at the revlog level helps the storage consistency story and simplify various things. Example of data we could store there: - copy tracing related informations - graph structure related information (useful for discovery) - unresolved conflict data The full implementation will be introduced gradually in the coming changesets. Differential Revision: https://phab.mercurial-scm.org/D6808
-
- Sep 25, 2019
-
-
Martin von Zweigbergk authored
merge.calculateupdate() takes a lot of parameters and I get confused all the time which is which. See also b14fdf1fb615 (update: clarify update() call sites by specifying argument names, 2017-02-09). Differential Revision: https://phab.mercurial-scm.org/D6883
-
Augie Fackler authored
All the callsites of this method have access to the repo, and I'd rather not have to duplicate this across alternative bmstore implementations. Besides, it feels like a bit of a layering violation. .. api:: `mercurial.bookmarks.bmstore` no longer has a convenience method for looking up changectx instances from a bookmark name. Use `repo[repo.bookmarks[name]]` intead of `repo.bookmarks.changectx(name)`. Differential Revision: https://phab.mercurial-scm.org/D6884
-
Augie Fackler authored
This bug is as old as histedit, which is more than 10 years! I'm a little sad about the extra calculations here that we're just going to throw out, but I don't see any better way to look for untracked file conflicts and I want the bug fixed. Differential Revision: https://phab.mercurial-scm.org/D6882
-
- Sep 23, 2019
-
-
Augie Fackler authored
I'm honestly impressed that nobody has hit this in the over a decade that histedit has existed, but here we are. Differential Revision: https://phab.mercurial-scm.org/D6881
-
- Sep 25, 2019
-
-
Paul Gossman authored
When --keep is passed with rebase, the new nodes created are not accessible from templates. This change enables accessing the newly-created nodes from nodechanges, just as if --keep was not set. Differential Revision: https://phab.mercurial-scm.org/D6880
-
- Sep 21, 2019
-
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D6874
-
- Sep 25, 2019
-
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D6875
-
Augie Fackler authored
This shouldn't make any difference for legal code, but it'll prevent the assertion from being optimized out if someone decides to do -O on our code. Differential Revision: https://phab.mercurial-scm.org/D6879
-
Augie Fackler authored
.. api:: `mercurial.hg.updatetotally` is now more thorough about checking its `updatecheck` keyword argument. Previously invalid values would have used the configured default updatecheck method, but now will raise ValueError. Differential Revision: https://phab.mercurial-scm.org/D6878
-
Augie Fackler authored
.. api:: `mercurial.hg.update*` and `mercurial.merge.update` now expect a value from a set of NAMED_CONSTANTS (`merge.UPDATECHECK_*` constants) rather than a collection of magic strings. As of now, the values are the same, but code should be prepared for these values to change in the future. Differential Revision: https://phab.mercurial-scm.org/D6877
-
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].
-