Mon, 28 Sep 2020 14:06:23 +0200 hg-core: return `Err` on decompression error (D8958#inline-15004 followup)
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 14:06:23 +0200] rev 45598
hg-core: return `Err` on decompression error (D8958#inline-15004 followup) Differential Revision: https://phab.mercurial-scm.org/D9100
Mon, 28 Sep 2020 14:01:57 +0200 hg-core: remove useless code (D8958#inline-14988 followup)
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 14:01:57 +0200] rev 45597
hg-core: remove useless code (D8958#inline-14988 followup) Differential Revision: https://phab.mercurial-scm.org/D9099
Mon, 28 Sep 2020 13:55:47 +0200 hg-core: minor docstring update (D8958#inline-14991 followup)
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 13:55:47 +0200] rev 45596
hg-core: minor docstring update (D8958#inline-14991 followup) Differential Revision: https://phab.mercurial-scm.org/D9097
Mon, 28 Sep 2020 13:53:11 +0200 hg-core: minor code style change (D8958#inline-14986 followup)
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 13:53:11 +0200] rev 45595
hg-core: minor code style change (D8958#inline-14986 followup) Differential Revision: https://phab.mercurial-scm.org/D9096
Mon, 28 Sep 2020 13:51:16 +0200 hg-core: Explain offset override of first revision
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 13:51:16 +0200] rev 45594
hg-core: Explain offset override of first revision (D8958#inline-14992 followup) Differential Revision: https://phab.mercurial-scm.org/D9095
Mon, 28 Sep 2020 13:46:14 +0200 hg-core: minor code style change (D8958#inline-14993 followup)
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 13:46:14 +0200] rev 45593
hg-core: minor code style change (D8958#inline-14993 followup) Differential Revision: https://phab.mercurial-scm.org/D9083
Thu, 24 Sep 2020 09:32:07 +0200 changing-files: move default constructor value to None
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 24 Sep 2020 09:32:07 +0200] rev 45592
changing-files: move default constructor value to None According to Augie Fackler, using tuple as default value confuse PyType when actual values are passed at init time. Differential Revision: https://phab.mercurial-scm.org/D9086
Mon, 28 Sep 2020 11:16:12 +0200 rust: format with rustfmt
Raphaël Gomès <rgomes@octobus.net> [Mon, 28 Sep 2020 11:16:12 +0200] rev 45591
rust: format with rustfmt I suppose I ran the formatter on the tip but not on every patch. Differential Revision: https://phab.mercurial-scm.org/D9093
Mon, 24 Aug 2020 15:35:34 +0530 merge: store cases when a file is absent post merge in commitinfo
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 24 Aug 2020 15:35:34 +0530] rev 45590
merge: store cases when a file is absent post merge in commitinfo Some merges can result in file being absent form working directory. This can be one of file was kept deleted or file was removed by merge code. User might revert the file back before committing. In such cases we will like to have better handling and create new filenodes. We store this info in mergestate as commitinfo so that we can use it while committing to create new filenode if required. Differential Revision: https://phab.mercurial-scm.org/D9003
Mon, 14 Sep 2020 15:08:15 +0530 tests: add some more debugmergestate calls in `test-merge-criss-cross.t`
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 15:08:15 +0530] rev 45589
tests: add some more debugmergestate calls in `test-merge-criss-cross.t` Differential Revision: https://phab.mercurial-scm.org/D9029
Thu, 03 Sep 2020 13:58:14 +0530 commit: force create a new filenode if it was set in mergestate by merge
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:58:14 +0530] rev 45588
commit: force create a new filenode if it was set in mergestate by merge For reasons mentioned in previous commits, we will like to forcefully create a new filenode sometimes. Combination of this patch and previous one, we fixed a case in `test-merge-combination.t`. This does not yet results in conflict where it should, I need to investigate more about what's happening as it should be a change-delete conflict now. Differential Revision: https://phab.mercurial-scm.org/D8989
Thu, 03 Sep 2020 13:44:06 +0530 merge: store commitinfo if these is a dc or cd conflict
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:44:06 +0530] rev 45587
merge: store commitinfo if these is a dc or cd conflict delete-changed or changed-delete conflicts can either be resolved by mergetool, if some tool is passed and using or by user choose something on prompt or user doing some `hg revert` after choosing the file to remain conflicted. If the user decides to keep the changed side, on commit we just reuse the parent filenode. This is mostly fine unless we are in a distributed environment and people are doing criss-cross merges. Since, we don't have recursive merges or any other way of describing the end result of the merge was an explicit choice and it should be differentiated from it's ancestors, merge algo during criss-cross merges fails to take in account the explicit choice made by user and end up with a what-can-be-said-wrong-merge. The solution which we are trying to fix this is by creating a filenode on commit instead of reusing the parent filenode. This helps differentiate between pre-merged filenode and post-merge filenode and kind of tells about the choice user made. To implement creating new filenode functionality, we store info about these files in mergestate so that we can read them on commit and force create a new filenode. Differential Revision: https://phab.mercurial-scm.org/D8988
Fri, 25 Sep 2020 13:58:05 +0530 mergestate: update _stateextras instead of reassinging
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 25 Sep 2020 13:58:05 +0530] rev 45586
mergestate: update _stateextras instead of reassinging `merge.applyupdates()` can store extras for a file and _stateextras may not be empty always. Hence reassigning loses the old values. We can directly update like this because we switched to using `collections.defaultdict` for `_stateextras` sometime ago.
Mon, 14 Sep 2020 14:11:45 +0530 tests: add some debugmergestate calls in `test-merge-criss-cross.t`
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:11:45 +0530] rev 45585
tests: add some debugmergestate calls in `test-merge-criss-cross.t` This will help notice the change in upcoming patches much better. Differential Revision: https://phab.mercurial-scm.org/D9028
Thu, 03 Sep 2020 13:54:46 +0530 tests: add few debugrevlogindex and a log call to see changes in next test
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:54:46 +0530] rev 45584
tests: add few debugrevlogindex and a log call to see changes in next test In upcoming patches, we will create a new filenode in couple of cases. Let's add some debugrevlogindex and a log call so that we can observe those changes better. Differential Revision: https://phab.mercurial-scm.org/D8987
Mon, 14 Sep 2020 14:40:12 +0530 merge: disable `m2-vs-ma` optimization if new filenode config is true
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:40:12 +0530] rev 45583
merge: disable `m2-vs-ma` optimization if new filenode config is true The `m2-vs-ma` optimization filters out the file which have not changed between second parent and the ancestor of the merge. This results in the m1-vs-m2 diff not processing those files. These files will be required when we are creating new filenode for salvaged cases as we need to track them to store in mergestate that file can be salvaged. Differential Revision: https://phab.mercurial-scm.org/D9027
Mon, 14 Sep 2020 14:31:23 +0530 configitems: add a new config option to control new filenode functionality
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:31:23 +0530] rev 45582
configitems: add a new config option to control new filenode functionality This series is adding functionality where we can force create a new filenode for some files on a merge-commit. This is meant to represent an explicit choice made by user and hence distingusing the file in the merged commit with the file in parent by creating a new filenode instead of using the parent one. This introduces a experimental config option under which this functionality will be hidden. A new testcase is added in tests/test-merge-criss-cross.t to test the new functionality while making the option does not break other scenarios. Differential Revision: https://phab.mercurial-scm.org/D9026
Wed, 23 Sep 2020 14:20:49 -0400 git: add test showing `hg commit -i` working on a git repo
Connor Sheehan <sheehan@mozilla.com> [Wed, 23 Sep 2020 14:20:49 -0400] rev 45581
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
Mon, 21 Sep 2020 11:53:44 -0700 merge: replace calls to hg.updaterepo() by merge.update()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 11:53:44 -0700] rev 45580
merge: replace calls to hg.updaterepo() by merge.update() The former no longer buys us anything. Differential Revision: https://phab.mercurial-scm.org/D9067
Mon, 21 Sep 2020 09:57:29 -0700 merge: add a higher-level update() for the common `hg update` use case
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 09:57:29 -0700] rev 45579
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
Wed, 23 Sep 2020 15:16:35 +0200 sidedata: simply read p2copies files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:35 +0200] rev 45578
sidedata: simply read p2copies files from the `ChangingFiles` object
Wed, 23 Sep 2020 15:16:16 +0200 sidedata: simply read p1copies files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:16 +0200] rev 45577
sidedata: simply read p1copies files from the `ChangingFiles` object
Wed, 23 Sep 2020 15:16:01 +0200 sidedata: simply read removed files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:01 +0200] rev 45576
sidedata: simply read removed files from the `ChangingFiles` object
Wed, 23 Sep 2020 15:15:46 +0200 sidedata: simply read added files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:15:46 +0200] rev 45575
sidedata: simply read added files from the `ChangingFiles` object
Wed, 23 Sep 2020 15:13:44 +0200 sidedata: add a `decode_files_sidedata` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:13:44 +0200] rev 45574
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.
Tue, 15 Sep 2020 15:37:32 +0200 changelog: add a `changes` property on `changelogrevision`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Sep 2020 15:37:32 +0200] rev 45573
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.
Tue, 22 Sep 2020 10:27:35 +0200 sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 22 Sep 2020 10:27:35 +0200] rev 45572
sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata` We are storing more than copies information, so lets make it clear.
Sat, 12 Sep 2020 21:45:37 +0900 log: pass around --rev option by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:45:37 +0900] rev 45571
log: pass around --rev option by walkopts
Sat, 12 Sep 2020 21:39:58 +0900 log: parse --limit option by logcmdutil.parseopts()
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:39:58 +0900] rev 45570
log: parse --limit option by logcmdutil.parseopts()
Sat, 12 Sep 2020 21:35:26 +0900 log: pass around --follow/--follow-first options by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:35:26 +0900] rev 45569
log: pass around --follow/--follow-first options by walkopts
Sat, 12 Sep 2020 21:06:16 +0900 log: introduce struct that carries log traversal options
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:06:16 +0900] rev 45568
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.
Sat, 12 Sep 2020 16:19:01 +0900 log: remove unused argument from _makerevset()
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 16:19:01 +0900] rev 45567
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.
Sat, 12 Sep 2020 16:11:10 +0900 log: remove stale comment about order of user revset
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 16:11:10 +0900] rev 45566
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."
Fri, 25 Sep 2020 17:51:34 +0200 rust: add `dirstate_tree` module
Raphaël Gomès <rgomes@octobus.net> [Fri, 25 Sep 2020 17:51:34 +0200] rev 45565
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
Fri, 24 Jul 2020 16:35:02 +0200 rust-dirstatemap: add #[timed] to dirstatemap read for comparison
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Jul 2020 16:35:02 +0200] rev 45564
rust-dirstatemap: add #[timed] to dirstatemap read for comparison Differential Revision: https://phab.mercurial-scm.org/D9084
Mon, 21 Sep 2020 11:12:58 -0700 merge: make low-level update() private (API)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 11:12:58 -0700] rev 45563
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
Mon, 21 Sep 2020 10:09:39 -0700 merge: use merge.clean_update() when applicable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 10:09:39 -0700] rev 45562
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
Fri, 18 Sep 2020 15:03:06 -0700 rebase: teach in-memory rebase to not restart with on-disk rebase on conflict
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Sep 2020 15:03:06 -0700] rev 45561
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
Thu, 24 Sep 2020 16:30:17 +0200 rust: update Cargo.lock
Raphaël Gomès <rgomes@octobus.net> [Thu, 24 Sep 2020 16:30:17 +0200] rev 45560
rust: update Cargo.lock Differential Revision: https://phab.mercurial-scm.org/D9080
Thu, 24 Sep 2020 16:30:00 +0200 rust-tests: add test to check if `Cargo.lock` is up-to-date
Raphaël Gomès <rgomes@octobus.net> [Thu, 24 Sep 2020 16:30:00 +0200] rev 45559
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
Tue, 01 Sep 2020 18:08:24 +0530 scmutil: introduce function to check whether repo uses treemanifest or not
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 01 Sep 2020 18:08:24 +0530] rev 45558
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
Thu, 03 Sep 2020 11:07:47 -0400 chg: make is possible to call by default an hg binary located next to chg
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 03 Sep 2020 11:07:47 -0400] rev 45557
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
Wed, 23 Sep 2020 14:44:21 +0200 phases: fix performance regression with Python 2
Joerg Sonnenberger <joerg@bec.de> [Wed, 23 Sep 2020 14:44:21 +0200] rev 45556
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
Wed, 23 Sep 2020 09:04:32 -0700 rebase: move check for unresolved conflicts into lower-level rebasenode()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 23 Sep 2020 09:04:32 -0700] rev 45555
rebase: move check for unresolved conflicts into lower-level rebasenode() I want to add another call to `rebasenode()` and it's better to not have to duplicate the check. Differential Revision: https://phab.mercurial-scm.org/D9075
Fri, 18 Sep 2020 15:40:26 -0700 rebase: add dryrun property to rebaseruntime
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Sep 2020 15:40:26 -0700] rev 45554
rebase: add dryrun property to rebaseruntime I want to be able to check the property in `rebaseruntime._rebasenode()`. Passing the value via the runtime is a convenient way. Differential Revision: https://phab.mercurial-scm.org/D9074
Wed, 23 Sep 2020 09:21:26 -0700 rebase: when collapsing, p1 == dest, so use the former only
Martin von Zweigbergk <martinvonz@google.com> [Wed, 23 Sep 2020 09:21:26 -0700] rev 45553
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
Fri, 18 Sep 2020 15:37:03 -0700 rebase: remove redundant isinmemory argument from _origrebase()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Sep 2020 15:37:03 -0700] rev 45552
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
Tue, 22 Sep 2020 23:18:37 -0700 largefiles: prevent in-memory merge instead of switching to on-disk
Martin von Zweigbergk <martinvonz@google.com> [Tue, 22 Sep 2020 23:18:37 -0700] rev 45551
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
Mon, 21 Sep 2020 09:56:48 -0700 merge: add a back_out() function to encapsulate update()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 09:56:48 -0700] rev 45550
merge: add a back_out() function to encapsulate update() I've sent several earlier patches adding `merge.clean_update()`, `merge.merge()` etc, one function for each use case. This patch continues that work. I plan to hide the complex `update()` eventually. Differential Revision: https://phab.mercurial-scm.org/D9064
Fri, 18 Sep 2020 17:19:49 +0530 tests: update test-share-safe to work with non-zstd versions
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 18 Sep 2020 17:19:49 +0530] rev 45549
tests: update test-share-safe to work with non-zstd versions zstd is not available always like pure py versions. Hence we wrap that part around `#if zstd`. To make sure the functionality is tested on pure version as well, I have added another requirement addition test. Differential Revision: https://phab.mercurial-scm.org/D9045
Tue, 15 Sep 2020 16:51:11 +0200 rhg: add a limited `rhg cat -r` subcommand
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 15 Sep 2020 16:51:11 +0200] rev 45548
rhg: add a limited `rhg cat -r` subcommand It only supports revision specification (rev or full hash) and the list of files to cat. Differential Revision: https://phab.mercurial-scm.org/D9052
Fri, 11 Sep 2020 17:32:53 +0200 hg-core: add a `CatRev` operation
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 11 Sep 2020 17:32:53 +0200] rev 45547
hg-core: add a `CatRev` operation Differential Revision: https://phab.mercurial-scm.org/D9051
Tue, 15 Sep 2020 16:46:57 +0200 hg-core: add `files_with_nodes` to `Manifest`
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 15 Sep 2020 16:46:57 +0200] rev 45546
hg-core: add `files_with_nodes` to `Manifest` Differential Revision: https://phab.mercurial-scm.org/D9050
Tue, 15 Sep 2020 16:45:27 +0200 hg-core: add path_encode
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 15 Sep 2020 16:45:27 +0200] rev 45545
hg-core: add path_encode Differential Revision: https://phab.mercurial-scm.org/D9049
Tue, 15 Sep 2020 10:52:28 +0200 hg-core: impl TryFrom<PathBuff> for HgPathBuf
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 15 Sep 2020 10:52:28 +0200] rev 45544
hg-core: impl TryFrom<PathBuff> for HgPathBuf Differential Revision: https://phab.mercurial-scm.org/D9048
Wed, 09 Sep 2020 14:53:15 +0200 rhg: add `--revision` argument to `rhg files`
Antoine Cezar <antoine.cezar@octobus.net> [Wed, 09 Sep 2020 14:53:15 +0200] rev 45543
rhg: add `--revision` argument to `rhg files` Add the option to list the tracked files of a revision given its number or full node id. Benched on a clone of moz-central where tip is 1671467:81deaa1a68ebb28db0490954034ab38ab269409d files -r 81deaa1a68ebb28db0490954034ab38ab269409d > out.txt hg 0m1.633s rhg 0m0.157s files -r 81deaa1a68ebb28db0490954034ab38ab269409d > /dev/null hg 0m0.415s rhg 0m0.143s Differential Revision: https://phab.mercurial-scm.org/D9015
Fri, 18 Sep 2020 16:52:16 +0200 hg-core: add a `ListRevTrackedFiles` operation
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 18 Sep 2020 16:52:16 +0200] rev 45542
hg-core: add a `ListRevTrackedFiles` operation List files tracked at a given revision. Differential Revision: https://phab.mercurial-scm.org/D9014
Wed, 09 Sep 2020 12:12:11 +0200 hg-core: simplify `list_tracked_files` operation
Antoine Cezar <antoine.cezar@octobus.net> [Wed, 09 Sep 2020 12:12:11 +0200] rev 45541
hg-core: simplify `list_tracked_files` operation Use directly `ListDirstateTrackedFiles` rather than having an operation builder. Differential Revision: https://phab.mercurial-scm.org/D9013
Fri, 18 Sep 2020 16:52:08 +0200 hg-core: add `Revlog.get_node_rev`
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 18 Sep 2020 16:52:08 +0200] rev 45540
hg-core: add `Revlog.get_node_rev` Find the revision of a node given its full hash. Differential Revision: https://phab.mercurial-scm.org/D9012
Wed, 09 Sep 2020 14:50:58 +0200 hg-core: add `Manifest` a specialized `Revlog`
Antoine Cezar <antoine.cezar@octobus.net> [Wed, 09 Sep 2020 14:50:58 +0200] rev 45539
hg-core: add `Manifest` a specialized `Revlog` A facade to `Revlog` to provide a `manifest` specific interface. Differential Revision: https://phab.mercurial-scm.org/D9011
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 tip