Summary:
The hgrc format is quite simple. Writing a parser directly actually has similar
complexity to the pest parser, but with improved performance. Therefore let's
migrate off pest.
Before:
% buck2 run @//mode/opt :bench --
parse 645KB file 89.872 ms
load system and user 1.877 ms
load repo 4.107 ms
After:
% buck2 run @//mode/opt :bench --
parse 645KB file 31.501 ms
load system and user 0.757 ms
load repo 2.360 ms
Reviewed By: zzl0
Differential Revision: D42054371
fbshipit-source-id: 7dc84154cabec52ed7910e12fbac894845770076
Summary: Add a way to find duplicated or overridden configs for cleanup purpose.
Reviewed By: muirdm
Differential Revision: D42035995
fbshipit-source-id: 138964ffcfb9896ea69a850d1a9369405cedfa99
Summary:
It's a super long (>4K) config. Code search shows it's not used anywehere.
Therefore let's drop it.
I checked that `configs.legacylist` is also unused.
Reviewed By: muirdm
Differential Revision: D42036006
fbshipit-source-id: 82b886b9eb6abb50cacef7ee0f868280d45ab0a8
Summary:
Part of the internal dynamicconfig logic is actually just static. Move the most
obvious function common() to static config to avoid parsing overhead.
I dropped "DO NOT ADD NEW ENTRIES IN THIS FUNCTION !!!" since it no longer
applies - there is no function, and the static config macro is the right place
to update static configs.
Reviewed By: muirdm
Differential Revision: D42036002
fbshipit-source-id: a815715c83b751340e0181e4630371fe3b6f7932
Summary:
Move the opensource dynamicconfig to statically compiled config used by the
Sapling identity. This should reduce parsing time and make the internal `sl`
behave more closely with the external `sl`.
Reviewed By: muirdm
Differential Revision: D42036011
fbshipit-source-id: d45d6de0bac49d2d9397ff0556a4130cf7c93a84
Summary:
Use the `ConfigSet::secondary` added by D42023337 to include statically
compiled builtin merge-tools and core python configs. This avoids parsing cost.
Reviewed By: muirdm
Differential Revision: D42036010
fbshipit-source-id: 20bd724c31c4b5924c7124a35c859c9c66784c5d
Summary:
The "dropping" tracing messages would be useful to figure out exactly what
parts of config files are ignored.
Reviewed By: muirdm
Differential Revision: D42035997
fbshipit-source-id: 7f9f92510d445b23d357ff3fd6f891f14dbc4f80
Summary:
The underlying Rust method `ensure_location_supersets` only needs to be called once.
It's already called for `load` and `reload` paths. Therefore it's unnecessary
to call `ensure_location_supersets` again.
Reviewed By: muirdm
Differential Revision: D42036012
fbshipit-source-id: e181775a88880ea95da6399996367d1e30a8b31e
Summary: See the previous diff for context. Remove it since it's no longer used.
Reviewed By: muirdm
Differential Revision: D42025934
fbshipit-source-id: 31598893c78b103fa09d262f107c660aeb3a566a
Summary:
`ensure_location_supersets` has 2 features:
1. Verify hgrc.dynamic matches /etc configs. Report mismatches. This was the
initial purpose as you can see from the function docstring. At that time
the idea was that dynamicconfig matches /etc configs exactly (we no longer
do that).
2. Enforce `configs.allowedlocations` and `configs.allowedconfigs`. This was
added later - wasn't mentioned in docstring.
Feature 1 does not actually work, since the filenames of the /etc configs are
supposed set by `configs.validationsubset`, but is empty in production setup.
Worse, the existing logic would treat all config items as "mismatch" and
`uiconfig.reportissues` will report near 1000 config items.
Since feature 1 is already not working as intended, this diff drops it.
Logging via Rust tracing is added for changes by feature 2. Note we cannot
rely on Python `uiconfig.reportissues` logging because
`ensure_location_supersets` is called multiple times and it can only report
mismatches the first time, while the Python code does not call it the first
time.
Reviewed By: muirdm
Differential Revision: D42024668
fbshipit-source-id: fbe5cf42e45fb1e68e2d32ec27fbdfe00cb62170
Summary:
Add a way to get some ideas about the overhead of config loading.
An example benchmark run shows:
$ cargo bench --bench bench -- system
load system and user 1.873 ms
load repo 2.052 ms
Reviewed By: muirdm
Differential Revision: D42036000
fbshipit-source-id: 3f566fb0c3f8369d3e257f845b4d803a6742dd26
Summary:
This makes ConfigSet more flexible. It can include other kind of configs
(ex. staticconfig, unionconfig, etc) to form layers of configs.
Reviewed By: muirdm
Differential Revision: D42023337
fbshipit-source-id: 436b688bb4aa661a5dbaf5086e11f6edf7affb7b
Summary:
Historically, I was under the impression that it was impossible
to create a pull request with a specific number. As you can see
in this diff, we had a `guess_next_pull_request_number()` helper
function that had a "pretty good" heuristic for guessing the next
pull request number, which made it likely that we could make
the number encoded in the branch name match that of the PR.
Unfortunately:
- This heuristic was not guaranteed to work 100% of the time,
due to either races or deleted issues that could throw off the count.
- Using this heuristic required that we create the pull requests
serially [from bottom to top of the stack] rather than in parallel.
However, today while reading the REST API docs for creating a
pull request (https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#create-a-pull-request),
I noticed it was possible to specify an `issue`:
> An issue in the repository to convert to a pull request. The issue title, body, and comments will become the title, body, and comments on the new pull request. Required unless `title` is specified.
Ah ha! This meant we could first create a number of GitHub
issues (in parallel!) with placeholder data and then use the numbers
from these issues when creating pull requests (also in parallel)!
This also means we know the PR number when choosing the branch
name (recall the branch cannot be changed after creating the PR).
This diff updates the existing `sl pr` command to take advantage
of this information.
Reviewed By: muirdm
Differential Revision: D42050143
fbshipit-source-id: a52694f6599c4ba99f568c538d557e6d10db72a6
Summary:
With this change, running `sl pr submit --draft` will create any *new*
pull requests in draft mode. Commits already associated with a pull
request will not have their draft status changed.
Reviewed By: muirdm
Differential Revision: D42048510
fbshipit-source-id: fd1d1f1f1268b4deb9135f0f75115bbcc48d9ebe
Summary:
As we are going to add more flags for `sl pr submit`, it no longer
works well to use `submit` as the default command. Though we
add `s` as an alias for `submit` so it does not require much typing.
Reviewed By: zzl0
Differential Revision: D42047829
fbshipit-source-id: 782339a44ec5b548b6fc5e61a32f8fb05c0c8fe4
Summary: This makes it easier to use for trait objects.
Reviewed By: muirdm
Differential Revision: D42024292
fbshipit-source-id: 490f817c368d472f4741830d2d7269ee38f9ada2
Summary: Add a way to specify a name to `ConfigSet`.
Reviewed By: muirdm
Differential Revision: D42024078
fbshipit-source-id: bb530e8fa6d2bf3ac7f73ca0ff076e60ac2887ea
Summary:
This makes it possible to modify a UnionConfig on the fly without recreating it
from scratch.
Reviewed By: muirdm
Differential Revision: D42024079
fbshipit-source-id: 7c583cacc7a4602b29ec1ad1a4cef910ffc8a357
Summary: This will be used by the next change.
Reviewed By: muirdm
Differential Revision: D42022088
fbshipit-source-id: 0df90da6a0a515e1a0e0030d94aa86ea6950b9b5
Summary:
The name "parser" no longer accurately reflects what the code does. Rename it
to "loader" to clarify.
Reviewed By: muirdm
Differential Revision: D42018937
fbshipit-source-id: 22a115b2277e78e48c4ac75d75c97d0ec0ff1a37
Summary:
The configparser became too bloat with dynamicconfig logic.
Move its core structure `ConfigSet` to a standalone crate so code using
`ConfigSet` have a lightweight alternative, and `ConfigSet` logic can
be developed independently without coupling with dynamicconfig.
Reviewed By: muirdm
Differential Revision: D42018678
fbshipit-source-id: 45d1e9458fdaa65b0242bad59dfd76c46dd516d1
Summary: It is no longer referred in other CMakeLists files.
Reviewed By: muirdm
Differential Revision: D42021268
fbshipit-source-id: d172a8ecf82c4764fc4477d0391015a3ec89961e
Summary:
It is only used by hg.rs. Move it to decouple the core ConfigSet features from
hg's business logic (`--config` flags).
Reviewed By: muirdm
Differential Revision: D42018679
fbshipit-source-id: a33b9adf0217288ec7bea997a6e3b81fb35cc123
Summary:
Previously it requires the sub-configs to match their parent config.
That actually seems inflexible. Relax the requirement so it can be
used in more places.
Reviewed By: muirdm
Differential Revision: D42018680
fbshipit-source-id: bf2be4cfe23175ce32738872a16efe906fbc5d29
Summary: Use abstraction to be more flexible.
Reviewed By: muirdm
Differential Revision: D42011185
fbshipit-source-id: 419edb17376a6939a8eac98653b6cac20464544f
Summary:
This allows `workingcopy` to work with other config implementations like
`UnionConfig` not just `ConfigSet`.
Reviewed By: muirdm
Differential Revision: D42011186
fbshipit-source-id: a721922511b900a977e9e629088197f0742ea21c
Summary: move GraphQL queries into consts module, so they can be reused by tests.
Reviewed By: bolinfest
Differential Revision: D42035497
fbshipit-source-id: 0f43e6b43a43c15b61f696858abdd5ae230a2c45
Summary: define `sl` as a shell function to `HGIDENTITY=sl hg`
Reviewed By: quark-zju
Differential Revision: D41965294
fbshipit-source-id: eb3eebb0dc184a3aae4bcb6ab541a42f9e8b82f8
Summary: Move the update_distance log up so it fires for the Edenfs case as well.
Reviewed By: quark-zju
Differential Revision: D41750022
fbshipit-source-id: 48df0a58c009bc5bb87d76495d942a53f3089d1a
Summary:
This was requested for `sl pr` in
https://github.com/facebook/sapling/issues/218,
though this diff adds support for signing commits in general, in Sapling.
Here's how it works:
- `sl config --local gpg.key <KEY>` to specify your key
- Now `gitcommittext()` takes an optional `str` for the `gpgsigningkey` if `gpg.key` is set and `gpg.enabled` is `true` (which is the default).
- The text of the unsigned commit object is constructed and then signed using `gpg --status-fd=2 -bsau <KEY>` with the text passed via stdin.
- The resulting signature is embedded into the original text to sign it. Note that the original PGP key goes through some minor formatting (`\r` is removed; lines must start with a space to avoid a `\n\n` sequence) before it is embedded.
I documented things to the best of my knowledge in `eden/website/docs/git/signing.md`.
Follow-up items:
- Show signed status in smartlog?
- Update `sl ghstack` to honor signing configuration when running `git commit-tree`.
- Update `sl pr` to honor signing configuration when running `git commit-tree`.
Reviewed By: quark-zju
Differential Revision: D41778874
fbshipit-source-id: 5018a0d8bea1b5e9293c05954db65f35dd3c7aff
Summary:
This was flagged in D41921132 (a443a6cfef), but I ignored it so I could
land the diff without commandeering to give sggutier credit
for authoring it while he's OOO.
Reviewed By: quark-zju
Differential Revision: D41972389
fbshipit-source-id: 9e0a4e6aff9371f70a4fba8257a88c4c77e2d190
Summary:
The latest Homebrew bottles for Apple Sillicon macOS built by our Github Actions were broken, as mentioned in https://github.com/facebook/sapling/issues/315 . This was caused due to updating the Formula template used by our Github actions to 3.11 but not updating the Github actions themselves to Python 3.11. This commit fixes that last part.
Pull Request resolved: https://github.com/facebook/sapling/pull/319
Test Plan:
Triggered a [build on a fork of the sapling repo](https://github.com/sggutier/sapling/releases/tag/0.1.20221211-120017-rcd410769), downloaded the bottle built by it, and checked that it ran properly on my M1 mac:
```
$ sl --version
Sapling 0.1.20221211-120017-rcd410769
$ file $(which sl)
/Users/sggutier/homebrew/bin/sl: Mach-O 64-bit executable arm64
$ otool -L $(which sl)
/Users/sggutier/homebrew/bin/sl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
/Users/sggutier/homebrew/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/Users/sggutier/homebrew/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1163.100.19)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)
/Users/sggutier/homebrew/opt/python@3.11/Frameworks/Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
$ sl dbsh -c "import sys; print(sys.version)"
3.11.0 (main, Nov 28 2022, 13:49:33) [Clang 14.0.0 (clang-1400.0.29.202)]
$ sl clone https://github.com/sggutier/sapling/ saplingtest && cd saplingtest && sl
remote: Enumerating objects: 677771, done.
remote: Counting objects: 100% (2847/2847), done.
remote: Compressing objects: 100% (1469/1469), done.
remote: Total 677771 (delta 1396), reused 2692 (delta 1261), pack-reused 674924
Receiving objects: 100% (677771/677771), 175.60 MiB | 2.59 MiB/s, done.
Resolving deltas: 100% (454743/454743), done.
From https://github.com/sggutier/sapling
* [new ref] 2857ac6b96 -> remote/main
6535 files updated, 0 files merged, 0 files removed, 0 files unresolved
@ 2857ac6b9 Today at 11:33 mbolin https://github.com/facebook/sapling/issues/317 remote/main
│ Add build instructions for Windows (https://github.com/facebook/sapling/issues/317)
~
$ touch something && sl st
warning: watchman has recently started (pid 1093) - operation will be slower than usual
? something
$ cd eden/scm && sl root
/Users/sggutier/saplingtest
```
Reviewed By: bolinfest
Differential Revision: D41921132
Pulled By: sggutier
fbshipit-source-id: 0ed4f2d6f214f02669e45c9c4b8cced7de9caa2e
Summary:
fix "repo changed while backing up" errors for non best effort runs
metalog reloads on transaction, so let's add a transaction
before that, we had lots of **false positives** "repo changed while backing up" errors because we read cached values
also, enable best effort mode for scm daemon, it locks the whole working copy after https://www.internalfb.com/diff/D34797187 (2e1b3436b3), which is not expected
Reviewed By: markbt
Differential Revision: D41871718
fbshipit-source-id: 14e222d0ccbcd6aa4a6dd773f2889aa0721c9842
Summary: use GitHubEndpoint instead of low level async make_request, then we will be able to use a fake GitHubEndpoint in testing environment.
Reviewed By: bolinfest
Differential Revision: D41818264
fbshipit-source-id: 4ec511821a2e0fddf17bf384b73f0fc72dccb5b4
Summary: Add `async graphql` method in GitHubCLIEndpoint, so other code can use GitHubEndpoint instead of low level `async make_request`, then we will be able to use a fake GitHubEndpoint in testing environment.
Reviewed By: bolinfest
Differential Revision: D41818267
fbshipit-source-id: f3b299d67ff23f4be12e3b19a27c1937030d2d98
Summary: this is not used by current code, remove it so we don't need to refactor this unused code in following diffs.
Reviewed By: quark-zju
Differential Revision: D41818266
fbshipit-source-id: 32674b89e0cdadaa2c1509aa84911d0ce0d58465
