mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 16:57:49 +03:00
ae737fe22c
Summary:
Previously fetch_bonsai_range returned all commits between `ancestor` and
`descendant`, but `ancestor` was included. This is usually not what we want and
it might be surprising and can lead to subtle bugs. As an example, next commit
in the stack might have failed pushrebases when it shouldn't do that.
This diff changes the semantic of the function to exclude an ancestor. This
function was used for 2 use cases:
1) Find changed files. find_rebased_set function was manually removing the
ancestor anyway, so there's no change in behaviour
2) To check that there are no case conflicts. Previously we were checking the
case conflicts with ancestor included, but that wasn't necessary. To prove that
let's go over the two possible situation:
i) This is a first iteration of the pushrebase
```
CB
SB |
| ...
... CA
SA
| /
root
```
in that case files introduced by root commit will be used to check if we have
case conflicts or not. But this is not necessary, because pushrebase assumption
is that CA::CB should not introduce any new case conflicts. Besides, even if
they added a case conflict then checking with just the files that were changed by root commit is
not enough to verify that.
Similar logic goes to SA::SB commits. Checking if root has any conflicts with
SA::SB commits doesn't make sense.
ii) This is not the first iteration of the pushrebase
```
CB
SB |
| ...
... CA
SA
|
O <- latest pushrebase attempt
... <- we rebased over these commits on the previous attempts
| /
root
```
In this case it's even easier. Commit O was verified on the previous iteration,
so no need to add it here again.
Reviewed By: aslpavel
Differential Revision: D24110710
fbshipit-source-id: 90dff253cba0013e9d5e401474132a152d473cae
|
||
|---|---|---|
| .. | ||
| benchmark | ||
| blobimport_lib | ||
| blobrepo | ||
| blobrepo_utils | ||
| blobstore | ||
| blobstore_sync_queue | ||
| bonsai_git_mapping | ||
| bonsai_globalrev_mapping | ||
| bonsai_hg_mapping | ||
| bookmarks | ||
| bulkops | ||
| cache_warmup | ||
| changesets | ||
| cmdlib | ||
| cmds | ||
| commit_rewriting | ||
| common | ||
| derived_data | ||
| edenapi_server | ||
| fastreplay | ||
| filenodes | ||
| filestore | ||
| git | ||
| gotham_ext | ||
| hgcli | ||
| hgproto | ||
| hook_tailer | ||
| hooks | ||
| lfs_import_lib | ||
| lfs_protocol | ||
| lfs_server | ||
| load_limiter | ||
| manifest | ||
| mercurial | ||
| metaconfig | ||
| microwave | ||
| mononoke_api | ||
| mononoke_commitcloud_bookmarks_filler | ||
| mononoke_hg_sync_job | ||
| mononoke_types | ||
| mutable_counters | ||
| newfilenodes | ||
| permission_checker | ||
| phases | ||
| pushrebase | ||
| reachabilityindex | ||
| regenerate_hg_filenodes | ||
| repo_client | ||
| repo_import | ||
| revset | ||
| scs_server | ||
| segmented_changelog | ||
| server | ||
| sshrelay | ||
| tests | ||
| time_window_counter | ||
| tunables | ||
| unbundle_replay | ||
| walker | ||
| Cargo.toml | ||
| README.md | ||
Mononoke
Mononoke is a next-generation server for the Mercurial source control system, meant to scale up to accepting thousands of commits every hour across millions of files. It is primarily written in the Rust programming language.
Caveat Emptor
Mononoke is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects.
The version that we provide on GitHub does not build yet.
This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:
- Full support for a standard
cargo build. - Open source replacements for Facebook-internal services (blob store, logging etc).
The current goal is to get Mononoke working on Linux. Other Unix-like OSes may be supported in the future