Console View
|
|
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
merge: replace calls to hg.updaterepo() by merge.update() The former no longer buys us anything. Differential Revision: https://phab.mercurial-scm.org/D9067 |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
| sidedata: simply read p1copies files from the `ChangingFiles` object | |||||||||||||
|
Connor Sheehan
sheehan@mozilla.com |
|
||||||||||||
|
git: add test showing `hg commit -i` working on a git repo Shows `hg commit -i` working on a git repo via the `git` extension. Adds working directory changes to files `alpha` and `beta`, then selects only `alpha` changes and commits them. As of now this would fail for a filename that includes uppercase characters due to the lack of case folding support in the extension. Differential Revision: https://phab.mercurial-scm.org/D9081 |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
| sidedata: simply read p2copies files from the `ChangingFiles` object | |||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
| sidedata: simply read removed files from the `ChangingFiles` object | |||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
merge: add a higher-level update() for the common `hg update` use case This is different from the `update()` function that I just made private. The new function is specifically for the normal `hg update` use case. It doesn't do a merge and it doesn't do a clean (forced) update. Differential Revision: https://phab.mercurial-scm.org/D9066 |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
|
sidedata: add a `decode_files_sidedata` function Right now the function mostly gather existing code to build a consistent object. However having this function allow us prepare all user code independently from the actual side data format change (and associated encoding/decoding changes) Strictly speaking, we could not need to passe the sidedata explicitly since we have access to it though the `changelogrevision` object. However, the short term goal is to drop that first parameter to only pass the sidedata binaries. |
|||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
|
log: remove stale comment about order of user revset _makerevset() no longer depends on the computed revs since ea3320015d54 "log: remove dead code to follow descendants if ascending revisions specified." |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
|
sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata` We are storing more than copies information, so lets make it clear. |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
|
changelog: add a `changes` property on `changelogrevision` For the sidedata storage we are moving toward "all in one" block containing the equivalent of a "ChangingFiles" instance. We do various refactoring beforehand to prepare the usage of theses new data in the code. Since the object use slots, the "property cache" tricks cannot be used, and we cache the value manually. |
|||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
|
log: remove unused argument from _makerevset() I want to make getrevs() reusable for other commands, but the dependency graph of this getrevs() function is a mess. Let's minimize it first. |
|||||||||||||
|
Pierre-Yves David
pierre-yves.david@octobus.net |
|
||||||||||||
| sidedata: simply read added files from the `ChangingFiles` object | |||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
|
log: introduce struct that carries log traversal options I tried to refactor logcmdutil.getrevs() without using an options struct, but none of these attempts didn't work out. Since every stage of getrevs() needs various log command options (e.g. both matcher and revset query need file patterns), it isn't possible to cleanly split getrevs() into a command layer and a core logic. So, this patch introduces a named struct to carry command options in slightly abstracted way, which will be later used by "hg grep" and "hg churn". More fields will be added to the walkopt struct. Type hints aren't verified. I couldn't figure out how to teach pytype to load its own attr type stubs in place of our .thirdparty.attr. Conditional import didn't work. s/^from \.thirdparty // is the only way I found pytype could parse the @attr.ib decorator. |
|||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
| log: pass around --rev option by walkopts | |||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
| log: pass around --follow/--follow-first options by walkopts | |||||||||||||
|
Yuya Nishihara
yuya@tcha.org |
|
||||||||||||
| log: parse --limit option by logcmdutil.parseopts() | |||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust-dirstatemap: add #[timed] to dirstatemap read for comparison Differential Revision: https://phab.mercurial-scm.org/D9084 |
|||||||||||||
|
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust: add `dirstate_tree` module Mercurial needs to represent the filesystem hierarchy on which it operates, for example in the dirstate. Its current on-disk representation is an unsorted, flat structure that gets transformed in the current Rust code into a `HashMap`. This loses the hierarchical information of the dirstate, leading to some unfortunate performance and algorithmic compromises. This module adds an implementation of a radix tree that is specialized for representing the dirstate: its unit is the path component. I have made no efforts to optimize either its memory footprint or its insertion speed: they're pretty bad for now. Following will be a few patches that modify the dirstate.status logic to use that new hierarchical information, fixing issue 6335 in the same swing. Differential Revision: https://phab.mercurial-scm.org/D9085 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
merge: make low-level update() private (API) We have very few callers left that call the low-level `merge.update()` function. I think it's time to make it private. I'll remove the remaining callers in coming patches, except for one call from the `rebase` module. I hope to eventually fix that too, but it's more complex because it requires teaching `merge.graft()` to work with a dirty working copy. Differential Revision: https://phab.mercurial-scm.org/D9065 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
merge: use merge.clean_update() when applicable We have had this higher-level function (higher than `merge.update()`, that is) for a while. Let's simply some callers by using it. I don't know why I didn't do this when I introduced the function. After this patch, there are no remaining callers that call `hg.updaterepo()` with `overwrite=True`. We'll clean that up soon. Differential Revision: https://phab.mercurial-scm.org/D9063 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
merge: make low-level update() private (API) We have very few callers left that call the low-level `merge.update()` function. I think it's time to make it private. I'll remove the remaining callers in coming patches, except for one call from the `rebase` module. I hope to eventually fix that too, but it's more complex because it requires teaching `merge.graft()` to work with a dirty working copy. Differential Revision: https://phab.mercurial-scm.org/D9065 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
rebase: teach in-memory rebase to not restart with on-disk rebase on conflict When in-memory rebase runs into conflicts, it redoes the whole rebase operation. This patch teaches it to instead discard just the current `overlayworkingctx` and redo that node on disk. I've tested this by enabling in-memory rebase by default and checking that there are no unexpected differences after this patch. The next step is to make it so that `hg rebase --continue` can use in-memory merge. Differential Revision: https://phab.mercurial-scm.org/D9076 |
|||||||||||||
|
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust-tests: add test to check if `Cargo.lock` is up-to-date An out-of-date `Cargo.lock` is the source of rebase conflicts, prevents a reproductible build, introduces desync between the series that introduces a change in dependencies and the one that eventually commits the `Cargo.lock`, and is just a general annoyance. This commit demonstrates that the test works, the next one fixes the currently out-of-date `Cargo.lock`. Differential Revision: https://phab.mercurial-scm.org/D9079 |
|||||||||||||
|
Joerg Sonnenberger
joerg@bec.de |
|
||||||||||||
|
phases: fix performance regression with Python 2 Unlike Python 3, xrange doesn't support efficient "in" and uses a linear time scan instead. Expand the condition to handle it fast. Differential Revision: https://phab.mercurial-scm.org/D9072 |
|||||||||||||
|
Pulkit Goyal
7895pulkit@gmail.com |
|
||||||||||||
|
scmutil: introduce function to check whether repo uses treemanifest or not In an upcoming patch, I wanted to check whether current repo uses treemanifest or not. I looked for a function and found that at all places we manually check for the requirement in repo requirements. I guess having a dedicated function for that is much better. Differential Revision: https://phab.mercurial-scm.org/D8981 |
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust: update Cargo.lock Differential Revision: https://phab.mercurial-scm.org/D9080 |
|||||||||||||
|
Valentin Gatien-Baron
vgatien-baron@janestreet.com |
|
||||||||||||
|
chg: make is possible to call by default an hg binary located next to chg When a single version of hg is in use and it's in the PATH, using chg is just a matter of calling chg. But when there are multiple installations of hg+chg around, and hg is referred to with an absolute path, using chg is more annoying because it requires both changing the invocation to hg to use chg, but also setting CHGHG. Currently, we set HGPATH when we build chg to remove the need to set CHGHG in the previous paragraph. But that means chg now hardcodes its installation path, which makes the installation not relocatable. Hence this proposal to make chg find ./hg relative to itself (as opposed to CHGHG=./hg which find hg relative to cwd). This only works on linux as written, but since it's opt-in, it sounds fine. Tested by hand, as I'm not sure how else to test this. Differential Revision: https://phab.mercurial-scm.org/D9006 |
|||||||||||||
|
Valentin Gatien-Baron
vgatien-baron@janestreet.com |
|
||||||||||||
|
chg: make is possible to call by default an hg binary located next to chg When a single version of hg is in use and it's in the PATH, using chg is just a matter of calling chg. But when there are multiple installations of hg+chg around, and hg is referred to with an absolute path, using chg is more annoying because it requires both changing the invocation to hg to use chg, but also setting CHGHG. Currently, we set HGPATH when we build chg to remove the need to set CHGHG in the previous paragraph. But that means chg now hardcodes its installation path, which makes the installation not relocatable. Hence this proposal to make chg find ./hg relative to itself (as opposed to CHGHG=./hg which find hg relative to cwd). This only works on linux as written, but since it's opt-in, it sounds fine. Tested by hand, as I'm not sure how else to test this. Differential Revision: https://phab.mercurial-scm.org/D9006 |
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust-tests: add test to check if `Cargo.lock` is up-to-date An out-of-date `Cargo.lock` is the source of rebase conflicts, prevents a reproductible build, introduces desync between the series that introduces a change in dependencies and the one that eventually commits the `Cargo.lock`, and is just a general annoyance. This commit demonstrates that the test works, the next one fixes the currently out-of-date `Cargo.lock`. Differential Revision: https://phab.mercurial-scm.org/D9079 |
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust: update Cargo.lock Differential Revision: https://phab.mercurial-scm.org/D9080 |
|||||||||||||
|
Pulkit Goyal
7895pulkit@gmail.com |
|
||||||||||||
|
scmutil: introduce function to check whether repo uses treemanifest or not In an upcoming patch, I wanted to check whether current repo uses treemanifest or not. I looked for a function and found that at all places we manually check for the requirement in repo requirements. I guess having a dedicated function for that is much better. Differential Revision: https://phab.mercurial-scm.org/D8981 |
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust: update Cargo.lock Differential Revision: https://phab.mercurial-scm.org/D9080 |
|||||||||||||
|
Raphaël Gomès
rgomes@octobus.net |
|
||||||||||||
|
rust-tests: add test to check if `Cargo.lock` is up-to-date An out-of-date `Cargo.lock` is the source of rebase conflicts, prevents a reproductible build, introduces desync between the series that introduces a change in dependencies and the one that eventually commits the `Cargo.lock`, and is just a general annoyance. This commit demonstrates that the test works, the next one fixes the currently out-of-date `Cargo.lock`. Differential Revision: https://phab.mercurial-scm.org/D9079 |
|||||||||||||
|
Pulkit Goyal
7895pulkit@gmail.com |
|
||||||||||||
|
scmutil: introduce function to check whether repo uses treemanifest or not In an upcoming patch, I wanted to check whether current repo uses treemanifest or not. I looked for a function and found that at all places we manually check for the requirement in repo requirements. I guess having a dedicated function for that is much better. Differential Revision: https://phab.mercurial-scm.org/D8981 |
|||||||||||||
|
Valentin Gatien-Baron
vgatien-baron@janestreet.com |
|
||||||||||||
|
chg: make is possible to call by default an hg binary located next to chg When a single version of hg is in use and it's in the PATH, using chg is just a matter of calling chg. But when there are multiple installations of hg+chg around, and hg is referred to with an absolute path, using chg is more annoying because it requires both changing the invocation to hg to use chg, but also setting CHGHG. Currently, we set HGPATH when we build chg to remove the need to set CHGHG in the previous paragraph. But that means chg now hardcodes its installation path, which makes the installation not relocatable. Hence this proposal to make chg find ./hg relative to itself (as opposed to CHGHG=./hg which find hg relative to cwd). This only works on linux as written, but since it's opt-in, it sounds fine. Tested by hand, as I'm not sure how else to test this. Differential Revision: https://phab.mercurial-scm.org/D9006 |
|||||||||||||
|
|||||||||||||
|
Sebastien Boisvert
sebhtml@protonmail.com |
|
||||||||||||
|
log: add support for bookmarks A bookmark can already be pushed with 'hg push origin -B topic-foo'. The pull command also supports bookmarks. This patch adds support for bookmarks using the '_opt2logrevset' code path. The list of changesets for a bookmark can now be obtained simply with: 'hg log -B topic-foo'. Reviewed-by: Elenie Godzaridis <arangradient@gmail.com> Differential Revision: https://phab.mercurial-scm.org/D8973 |
|||||||||||||
|
|||||||||||||
|
Joerg Sonnenberger
joerg@bec.de |
|
||||||||||||
|
phases: fix performance regression with Python 2 Unlike Python 3, xrange doesn't support efficient "in" and uses a linear time scan instead. Expand the condition to handle it fast. Differential Revision: https://phab.mercurial-scm.org/D9072 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
rebase: when collapsing, p1 == dest, so use the former only `dest` is the destination we're rebasing onto, which is always the same as `p1` when using `--collapse`. This lets us simplify a bit. Differential Revision: https://phab.mercurial-scm.org/D9073 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
largefiles: prevent in-memory merge instead of switching to on-disk I enabled in-memory merge by default while testing some changes. I spent quite some time troubleshooting why largefiles was still creating an on-disk mergestate. Then I found out that it ignores the callers `wc` argument to `mergemod._update()` and always uses on-disk merge. This patch changes that so we raise an error if largefiles is used with in-memory merge. That way we'll notice if in-memory merge is used with largefiles instead of silently replacing ignoring the `overlayworkingctx` instance and updating the working copy instead. I felt a little bad that this would break things more for users with both largefiles and in-memory rebase enabled. So I also added a higher-level override to make sure that largefiles disables in-memory rebase. It turns out that that fixes `run-tests.py -k largefiles --extra-config-opt rebase.experimental.inmemory=1`. Differential Revision: https://phab.mercurial-scm.org/D9069 |
|||||||||||||
|
|||||||||||||
|
Martin von Zweigbergk
martinvonz@google.com |
|
||||||||||||
|
rebase: remove redundant isinmemory argument from _origrebase() The argument is redundant with `rbst.inmemory`, which makes it unclear what to do if they were somehow different. Differential Revision: https://phab.mercurial-scm.org/D9070 |
|||||||||||||
|
|||||||||||||