- Jul 21, 2019
-
-
Yuya Nishihara authored
Otherwise warn() in match.py would fail if the warning contains non-ASCII character. We might want to add a thin ByteString wrapper around Vec<u8> to implement ToPyObject<ObjectType = PyBytes>, but I'm not sure.
-
Yuya Nishihara authored
The last example, [\#], is what the rust implementation fails to parse. The other escapes can be removed by regexp engine or _globre().
-
Yuya Nishihara authored
-
Yuya Nishihara authored
"\\<char>" is not an escape character but "\\" + <char>.
-
- Jul 20, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6662
-
- Jul 19, 2019
-
-
Martin von Zweigbergk authored
We were shadowing the "node" variable, so we always passed None to the LookupError instead of the node we meant to pass. (This showed up in py3 tests since py3 doesn't like to format None using "%s".) Differential Revision: https://phab.mercurial-scm.org/D6661
-
- Jul 18, 2019
-
-
Augie Fackler authored
I'm not clear why this behaves very slightly differently on Python 3, but I'm also not concerned about it. Differential Revision: https://phab.mercurial-scm.org/D6658
-
Taapas Agrawal authored
The description for registration of new `continuefunc` or `abortfunc` is removed as it is not required from user perspective. Differential Revision: https://phab.mercurial-scm.org/D6660
-
- Jul 21, 2019
-
-
Matt Harbison authored
The Windows bot is slow enough that it was 2s in the first hunk. Differential Revision: https://phab.mercurial-scm.org/D6663
-
- Jul 18, 2019
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6656
-
Augie Fackler authored
For some reason the import checker only caught this on py3. Differential Revision: https://phab.mercurial-scm.org/D6657
-
Navaneeth Suresh authored
We now have `unshelve --interactive` after rHG5162753c4c14. So, the help text on `shelve --interactive` suggesting that it only works for `shelve` can be removed. Differential Revision: https://phab.mercurial-scm.org/D6654
-
Navaneeth Suresh authored
This is a follow-up patch to rHG5162753c4c14. We have the logic for interactive unshelve under `_rebaserestorecommit()`. So, we might get conflicts even if there are conflicting changes other than selected changes by the user. We should mark unshelve `--interactive` as `EXPERIMENTAL` until we solve this issue. Differential Revision: https://phab.mercurial-scm.org/D6653
-
- Jul 02, 2019
-
-
sliquister authored
Currently, the files list of merge commits repeats all the deletions (either actual deletions, or files that got renamed) that happened between base and p2 of the merge. If p2 is the main branch, the list can easily be much bigger than the change being merged. This results in various problems worth improving: - changelog is bigger than necessary - `hg log directory` lists many unrelated merge commits, and `hg log -v -r commit` frequently fills multiple screens worth of files - it possibly slows down adjustlinkrev, by forcing it to read more manifests, and that function can certainly be a bottleneck - the server side of pulls can waste a lot of time simply opening the filelogs for pointless files (the constant factors for opening even a tiny filelog is apparently pretty bad) So stop listing such files as described in the code. Impacted merge commits and their descendants get a different hash than they would have without this. This doesn't seem problematic, except for convert. The previous commit helped with that in the hg->hg case (but if you do svn->hg twice from scratch, hashes can still change). The rest of the description is numbers. I don't have much to report, because recreating the files list of existing repositories is not easy: - debugupgradeformat and bundle/unbundle don't recreate the list - export/import tends to choke quickly applying patches or on description that contain diffs, - merge commits from the convert extension don't have the right files list for reasons orthogonal to the current commit - replaying the merge with hg update/hg merge/hg revert --all/hg commit can end up failing in hg revert - I wasn't sure that using debugsetparents + debugrebuilddirstate would really build the right thing I measured commit time before and after this change, in a case with no files filtered out, several files filtered out (no difference) and 5k files filtered out (+1% time). Recreating the 100 more recent merges in a private repo, the concatenated uncompressed files lists goes from 1.12MB to 0.52MB. Excluding 3 merges that are not representative, then the size goes from 570k to 15k. I converted part of mozilla-central, and observed file list shrinking quite a bit too, starting at the very first merge, 733641d9feaf, going from 550 files to 10 files (although they have relatively few merges, so they probably wouldn't care). Differential Revision: https://phab.mercurial-scm.org/D6613
-
- Jul 14, 2019
-
-
sliquister authored
I want to change the computation of the list of files modified by a commit. In principle, this would simply change a cache. But since this information is stored in commits rather than a cache, changing it means changing commit hashes (going forward). Some users rely on the convert extension from hg to hg not changing hashes when nothing changes (usually). Allow these users to preserve hashes despite changes to the changelog files computation by reusing these files lists when the manifest is unchanged (since these files list are derived from the manifest). Differential Revision: https://phab.mercurial-scm.org/D6643
-
- Jul 02, 2019
-
-
sliquister authored
I don't think there's coverage for many of the subtle cases, and I found it hard to understand what the code is doing by reading it. The test takes 40s to run on a laptop, or 9s with --chg. I have yet to find a description of what the files field is supposed to be for merges. I thought it could be one of: 1. the files added/modified/removed relative to p1 (wouldn't seem useful, but `hg diff -c -r mergerev` has this behavior) 2. the files with filelog nodes not in either parent (i.e., what is needed to create a bundle out of a commit) 3. the files added/removed/modified files by merge itself [1] It's clearly not 1, because file contents merges are symmetric. It's clearly not 2 because removed files and exec bit changes are listed. It's also not 3 but I think it's intended to be 3 and the differences are bugs. Assuming 3, the test shows that, for merges, the list of files both overapproximates and underapproximates. All the cases involve file changes not in the filelog but in the manifest (existence of file at revision, exec bit and file vs symlink). I didn't look at all underapproximations, but they looked minor. The two overapproximations are problematic though because they both cause potentially long lists of files when merging cleanly. [1] even what it means for the merge commit itself to change a file is not completely trivial. A file in the merge being the same as in one of the parent is too lax as it would consider that merges change nothing when they revert all the changes done on one side. The criteria used in the test and in the next commit for "merge didn't touch a file" is: - the parents and the merge all have the same file - or, one parent didn't touch the file and the other parent contains the same file as the merge Differential Revision: https://phab.mercurial-scm.org/D6612
-
- Jul 16, 2019
-
-
Ian Moody authored
When setting local:commits arcanist has different behaviour depending on whether the repo is git or hg. With hg it sets the time as a number, since it calls PHP's strtotime on the value, but with git it sets it as a string. Normally this wouldn't be an issue since phabread wouldn't be interacting with Phabricator Revisions for git repos, but Mozilla has a secondary workflow for git users that uses the git-cinnabar tool to interact with their hg repos. When a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central it makes use of Mozilla's fork of arcanist, which works with their local git version of m-c, and thus sets the local:commit time as a string, and then translates the commit hashes. Currently when encountering such DREVS phabread dies with "TypeError: %d format: a number is required, not str". phabsend also used to set it as a string but wouldn't have encountered the issue with its own DREVs since it would read hg:meta first. Differential Revision: https://phab.mercurial-scm.org/D6650
-
Ian Moody authored
Differential Revision: https://phab.mercurial-scm.org/D6649
-
- Jul 02, 2019
-
-
Navaneeth Suresh authored
Until now, there is no way to `unshelve` selected changes only from the stored shelve as given in issue6162. This patch makes `unshelve` perform with certain changes only by adding an interactive mode. Differential Revision: https://phab.mercurial-scm.org/D6596
-
- Jul 07, 2019
-
-
sliquister authored
This is maybe not the best way to go about fixing this, but anything is better than the status quo. Differential Revision: https://phab.mercurial-scm.org/D6611
-
- Jul 17, 2019
-
-
Taapas Agrawal authored
This patch adds the support for `ushelve` in `hg continue` plan. `hgcontinueunshelve()` has been created for independent calls. In case an interrupted unshelve is resumed via hg continue the shelvedstate needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgcontinueunshelve()` is then registered as `continuefunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6652
-
- Jul 15, 2019
-
-
Taapas Agrawal authored
This adds support of rebase to hg continue plan. An independent continue logic for rebase is created under continuerebase() function. For this a seperate rebaseruntime object is created under the function to handle an interrupted rebasestate. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6646
-
Taapas Agrawal authored
This is part of GSoC19 project `Implement abort and continue commands`. This patch is part of the continue plan. This adds the basic logic for hg continue. This command aborts an multistep operation like graft, histedit, rebase, transplant and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under statemod. This API is extended to support hg continue by adding a method to register the abort logic as a function (here continuefunc). Once the unfinished operation is determined the registered logic is used to resume the command in case it is interrupted. The benefit of this kind of framework is that any new extension developed can support hg continue by registering the command and logic under statedetection API. hg continue currently supports --dry-run/-n flag only. It is used to dry run hg abort Differential Revision: https://phab.mercurial-scm.org/D6645
-
- Jul 17, 2019
-
-
Raphaël Gomès authored
While this assertion had good intentions, it broke existing behavior with a nasty panic. Differential Revision: https://phab.mercurial-scm.org/D6651
-
- Jul 10, 2019
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D6635
-
- Jul 02, 2019
-
-
Raphaël Gomès authored
Many interesting changes have happened in Rust since the Oxidation Plan was introduced, like the 2018 edition and procedural macros: - Opting in to the 2018 edition is a clear benefit in terms of future proofing, new (nice to have) syntactical sugar notwithstanding. It also has a new non-lexical, non-AST based borrow checker that has fewer bugs(!) and allows us to write correct code that in some cases would have been rejected by the old one. - Procedural macros allow us to use the PyO3 crate which maintainers have expressed the clear goal of compiling on stable, which would help in code maintainability compared to rust-cpython. In this patch are the following changes: - Removing most `extern crate` uses - Updating `use` clauses (`crate` keyword, nested `use`) - Removing `mod.rs` in favor of an aptly named module file Like discussed in the mailing list ( https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html ), until Rust integration in Mercurial is considered to be out of the experimental phase, the maximum version of Rust allowed is whatever the latest version Debian packages. Differential Revision: https://phab.mercurial-scm.org/D6597
-
- Jul 12, 2019
-
-
Raphaël Gomès authored
In cad3dde7a573, the `find_dirs` util was introduced, but the second changeset that made use of it didn't apply. This change fixes the issue. Differential Revision: https://phab.mercurial-scm.org/D6639
-
- Jul 16, 2019
-
-
Matt Harbison authored
Otherwise, the path components allrantogether. Differential Revision: https://phab.mercurial-scm.org/D6648
-
- Jul 15, 2019
-
-
Martin von Zweigbergk authored
The implementation is identical to the version inherited from basectx. Differential Revision: https://phab.mercurial-scm.org/D6647
-
- Jul 12, 2019
-
-
Matt Harbison authored
The test runner doesn't always guess the right location when optional output is missing. This goes with f6540aba8e3e. Differential Revision: https://phab.mercurial-scm.org/D6640
-
- Jul 10, 2019
-
-
Taapas Agrawal authored
Labels are used to label the code that belongs to `working copy` and `merge rev` in case of a conflicted state. No such labelling is required while aborting merge as conflicted parts are reverted to normal. Differential Revision: https://phab.mercurial-scm.org/D6638
-
- Jul 13, 2019
-
-
Martin von Zweigbergk authored
branchmap.branchcache, among other classes, defines a iteritems(). That currently gets replaced by items() by the source transformer. That makes it harder for extensions to work with both py2 and py3, since they have to call either items() or iteritems() on branchcache. Let's not replace definitions of iteritems() (and itervalues()) and only replace the call-sites. We need to also add an items() alias to branchcache (etc) so our transformer call-sites will find it. Differential Revision: https://phab.mercurial-scm.org/D6641
-
- Jul 15, 2019
-
-
Martin von Zweigbergk authored
`"%s" % None` does not work on py3. I've extracted a little function for producing a formatted message given the filter name. Differential Revision: https://phab.mercurial-scm.org/D6644
-
- Jul 14, 2019
-
-
Matt Harbison authored
I haven't tried building the x86 installer, but happened to notice this when working on the thg installer. Experimenting in PowerShell seems to show that LIBPATH was expanded at the end, but with ':' between, it effectively corrupted `${root}\WinSDK\Lib` and the first path in LIBPATH. Differential Revision: https://phab.mercurial-scm.org/D6642
-
- Jun 29, 2019
-
-
Taapas Agrawal authored
This adds support of `hg merge --abort` to `hg abort` plan. This involves refactoring `hg.merge` into two different functions removing the abort logic of `merge` from `hg.merge` and then creating a seperate `hg.abortmerge` to handle the abort logic so that the abortion of merge can be called independently. `hg.abortmerge` is then registered as `abortfunc` for the state detection API so that `commands.abort` can use it to deal with an unfinished merge operation. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6588
-
- Jun 26, 2019
-
-
Taapas Agrawal authored
This patch adds the support for shelve in `hg abort` plan. For this the logic to load a `shelvedstate` and the error handling for it had been shifted to a seperate function `_loadunshelvedstate()`. This returns a tuple with `state` file and `opts.` `hgabortunshelve()` has been created for independent calls. In case abortion of `unshelve` is called via `hg abort` the `shelvedstate` needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgabortunshelve()` is then registered as `abortfunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6579
-
- Jul 10, 2019
-
-
Taapas Agrawal authored
This changes the message type of Corruptedstate error in case of `hg unshelve --abort` to error.Abort from warning message. This is done so as to avoid the return statement after the warning. Differential Revision: https://phab.mercurial-scm.org/D6636
-
- Jun 19, 2019
-
-
Taapas Agrawal authored
Differential Revision: https://phab.mercurial-scm.org/D6548
-
- Jul 09, 2019
-
-
Martin von Zweigbergk authored
Since __doc__ is str, it seems natural that _origdoc also is. Differential Revision: https://phab.mercurial-scm.org/D6623
-
- Jun 28, 2019
-
-
Martin von Zweigbergk authored
As in the previous patch, consider these two histories: @ 4 'rename x to y' | o 3 'add x again' | o 2 'remove x' | | o 1 'modify x' |/ o 0 'add x' @ 4 'rename x to y' | o 3 'add x again' | | o 2 'modify x' | | | o 1 'add x' |/ o 0 'base' We trace copies from the 'modify x' commit to commit 4 by going via the merge base (commit 0). When tracing file 'y' (_tracefile()) in the first case, we immediately find the rename from 'x'. We check to see if 'x' exists in the merge base, which it does, so we consider it a valid copy. In the second case, 'x' does not exist in the merge base, so it's not considered a valid copy. As a workaround, this patch makes it so we also attempt the check in mergecopies's base commit (commit 1 in the second case). That feels pretty ugly to me, but I don't have any better ideas. Note that we actually also check not only that the filename matches, but also that the file's nodeid matches. I don't know why we do that, but it was like that already before I rewrote mergecopies(). That means that the rebase will still fail in cases like this (again, it already failed before my rewrite): @ 4 'rename x to y' | o 3 'add x again with content X2' | o 2 'remove x' | | o 1 'modify x to content X2' |/ o 1 'modify x to content X1' | o 0 'add x with content X0' Differential Revision: https://phab.mercurial-scm.org/D6604
-