Summary:
Add a devcontainer config
My laptop is full of weird versions of weird tools. Sapling requires specific versions of specific tools. It's nice to be able to open the sapling folder in vscode and get a prompt for "would you like to do your development inside a container with all the correct tools pre-installed?" :) This also allows people on github to click a button to open in github's web-based container-IDE and start developing without installing anything at all, though I don't know if we'd expect anybody to do that
For starters I'm using the CI build image without changes to try and keep the maintenance burden as small as possible, though it would be possible to use a separate layer within the Dockerfile (eg if we wanted to install extra tools that are useful for dev but not needed for building), or have a totally separate Dockerfile
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/sapling/pull/807).
* __->__ https://github.com/facebook/sapling/issues/807
* https://github.com/facebook/sapling/issues/806
* https://github.com/facebook/sapling/issues/804
Pull Request resolved: https://github.com/facebook/sapling/pull/807
Differential Revision: D52575911
Pulled By: quark-zju
fbshipit-source-id: b24e1a21493f18a06355c984a72936cd11fef2ea
Summary: add a comment explaining the sizes are not random anymore
Reviewed By: RajivTS
Differential Revision: D52870668
fbshipit-source-id: b6fa3669d5383dadf6913abe42ab2bdf95202ee0
Summary:
The git objects that get uploaded for a repo during repo import are not directly mapped to the commit. Hence, fetching those objects can be a bit different than raw blobstore access. Additionally, the objects can be ZLib encoded and the blob objects are stored using the filestore chunking abstraction. Having a dedicated newadmin command that can help in fetching these objects will be useful for debugging and support purposes.
I plan to make use of these during git-protocol implementation.
Reviewed By: gustavoavena
Differential Revision: D52843357
fbshipit-source-id: 6d0a0d774396523227e8ea313f02ee720b6c3d92
Summary:
This fixes the problem highlighted in the previous commit in this stack.
Let's add some discovery logic that will try to traverse the repo in a search for first commit that's not yet imported. To make that fast we're doing exponential jumps. This works well for single-threaded branches. Doesn't work all that well for merge commits (as we follow only p1 history) but it won't be worse than what we're doing right now.
Differential Revision: D52841546
fbshipit-source-id: d56f685eef30405e9f0d4942778267030a8f79a1
Summary:
Apply CSS to the `AnimatedReorderGroup` `div` directly so we can use flexbox
for layout. This seems nicer since `translate` might render at sub-pixel
(non-integer `px`) that looks blurry.
Reviewed By: evangrayk
Differential Revision: D52851255
fbshipit-source-id: 0f6753a00bc7f124f4acc33006335feca85616de
Summary:
The `AnimatedReorderGroup` uses a `<div>` already. Update the types so one can
pass in class names and flex layout properties.
Reviewed By: evangrayk
Differential Revision: D52851256
fbshipit-source-id: 8745f75d8d4237dc52658107014fa545a6a2fa03
Summary:
Animation can hurt productivity. Popular applications that draw context menu on
their own, like VS Code (Windows), FireFox, JetBrains Fleet, do not seem to use
animations for context menus. Chrome (and Edge) only recently starts showing
menu fading animation but I can see that fading animation hurting productivity.
I personally find fading in/out, zooming in/out annoying if the duration is
long too. The sliding animation can be useful to indicate what items are moving
to what destinations (so we added it to the edit stack UI).
Animations also varies on OS - the flashing behavior is a macOS behavior. On
Windows the OS behavior is to fade out the selected item. There are other
complexities on the fade out in theory - need to disable `:hover` and "pin"
selection, and need `pointer-events: none`.
For now, let's just remove the macOS-like context menu animations. This avoids
issues like hovering different items during the fade-out, CSS animation
out-of-sync with setTimeout, etc.
Reviewed By: evangrayk
Differential Revision: D52107206
fbshipit-source-id: 6d0eb1f198d5ae3aeb67bde8659f4a70c66941c2
Summary: This makes it easier to see the menu item worked.
Reviewed By: evangrayk
Differential Revision: D52824797
fbshipit-source-id: 68473d52e6f988d13aacdf688797a96bfb5f98f1
Summary:
This "copy to clipboard" behavior is widely used. Add a function to make it
easy to copy with a toast message.
Reviewed By: evangrayk
Differential Revision: D52824796
fbshipit-source-id: 08557c3a0f96831e09bc0175caa8a27a742ed504
Summary: Shows toasts in the top level.
Reviewed By: evangrayk
Differential Revision: D52849080
fbshipit-source-id: 70c79dee668b5a8cd3e36a61b7894e8fb6eafa32
Summary:
Add some states for temporary (toast) messages. Intended for things like
"Copied <text>".
Reviewed By: evangrayk
Differential Revision: D52824798
fbshipit-source-id: ecba4d74fde23e867c6aa876c268436d2d39f19a
Summary:
Similar to D52055047 but for another test.
An alternative could be setting a fixed date, like:
jest
.useFakeTimers()
.setSystemTime(new Date('2000-01-01'));
Reviewed By: evangrayk
Differential Revision: D52849081
fbshipit-source-id: 74e86c2e56a78212a2be8a2e12b2545ac2d0c707
Summary: After removing HgImporter there are still a few places where the name persists. Let's fix that. Renaming the thread pool factory to SaplingRetryThreadFactory and the thread pool member to retryThreadPool_. Also updated some docs to reflect and converted from Mercurial to Sapling.
Reviewed By: mshroyer, genevievehelsel
Differential Revision: D52571338
fbshipit-source-id: 4738c522d642d7a8aa66a368440e54b144a241b3
Summary: The last diff introduced and explained a corner case bug that I encountered in the delta logic and this diff fixes it. I have verified it through the unit test mentioned here but also through using the Git codebase by running the `test-tool delta` binary. P1045265393 is my VSCode launch config on my Mac in case someone else wants to try it out.
Reviewed By: mitrandir77
Differential Revision: D52841146
fbshipit-source-id: cb00e372c41914d221839858c0adb2eed96e2d74
Summary:
When trying to clone `whatsapp/server` and `whatsapp/iphone` repos from Mononoke bundle, the clone would fail with `delta replay gone bad` error. I spent a lot (lot!!) of time debugging with the git binary trying to identify the incorrect piece of data. I came across an edge case where the final instructions would involve just using the data from the target base file where the base file has nothing to offer. In this case, the diff range produced (for the base file) would be `Lb..Lb` where `Lb` is the size of the base file.
If we are doing delta at byte level (i.e. delta chunk size = 1), then this is not a problem since `(Lb * 1)..(Lb * 1)` represents an empty range which just gets skipped over. However for multi byte deltas (i.e. delta chunk size N where N > 1), the range becomes `(Lb * N)..(Lb * N)`. The code has guardrails for the end of the range with the conditions: `end_range = min(index * N, Lb)` however there is no such guardrail for the start of the range. Thus, we end up with the range `Lb1..Lb` where `Lb1 > Lb`.
This unit test captures this pathological case and panics in face of such input. In the follow up diff I will fix this bug and the same test case would start working.
Reviewed By: mitrandir77
Differential Revision: D52840293
fbshipit-source-id: 46649b935589d654f2df6038c41aabb09aa1b8ac
Summary: We already have a method to fetch raw git object bytes from the underlying store. This diff just adds a variant that can return the parsed object to maintain parity with the non-blob methods.
Differential Revision: D52710513
fbshipit-source-id: 63ba59f5d30a068f8bba2e0cb8967df280ab5ba5
Summary: A while back I added the hash translation in our filestore newadmin command for `git-sha1` and `seeded_blake3` hash. However since they were enabled in the hash types within the clap argument, they could not be used. This diff make the small change to add the new hashes.
Differential Revision: D52703891
fbshipit-source-id: c730839bfcdbab6b9437b1d247078a709d6e362f
Summary: With the removal of all HgImporter code, we no longer need to differentiate fetch_miss sources. If in the future we have other data stores that fetch from we can add this back. For now, it is just taking up extra space in our scuba table.
Reviewed By: genevievehelsel
Differential Revision: D52404111
fbshipit-source-id: 792d424d5b0459cdd0e47dad45d4bfb1298a1b3d
Summary: HgImporter is no longer in use in our codebase. We can now safely remove it.
Reviewed By: genevievehelsel
Differential Revision: D51911685
fbshipit-source-id: 239d70fb89a5db364606cb0140bc585fc5128324
Summary: We had already removed fetching trees and blobs. Now, we need to remove the last bits of HgImporter.
Reviewed By: genevievehelsel
Differential Revision: D51911205
fbshipit-source-id: 07bdaf14a62f7af951eafa7e8720f681914ba3ab
Summary: HgImporter is being removed - this change removes its support for fetching trees.
Reviewed By: kmancini
Differential Revision: D51872978
fbshipit-source-id: 5b373565c6b29ecc3dc7988695b6e4f62d9a04fb
Summary: HgImporter is being removed - this change removes its support for importing blobs.
Reviewed By: kmancini
Differential Revision: D51832464
fbshipit-source-id: 504a307e3c5cb66366f50a43362667e709512552
Summary:
Fix two issues in high contrast themes:
- "You are here" should have a border to be easier to see
- selected commits should have a border since the selection highlight is very subtle or invisible otherwise
Reviewed By: quark-zju
Differential Revision: D52822316
fbshipit-source-id: e0c4cb6ad72340a11f2e2a6f60b62c719e54b4be
Summary: Add a `title` field to commit dates, so you can hover to see the full time. I used `title` instead of a `<Tooltip>` for simplicity.
Reviewed By: quark-zju
Differential Revision: D52819843
fbshipit-source-id: 12fad7b5e1761e87920796eb9d6f30276c530c05
Summary:
adjust allowed concurrency for trees fetches
I have analysed sizes of batches in EdenFs and our concurrency setting
internally in Mononoke. I can see that by large extend overall performance is
limited by our own settings but we still have headroom to bump them.
eden batch size for trees is 128, so let's change our concurrency limit to 32.
We have other protection like cachelib shards limit, requests load limit, etc, to keep out throuput
bounded.
https://fburl.com/scuba/mononoke_test_perf/f7suzogx
we will be checking performance impact for >10 batches: https://fburl.com/scuba/mononoke_test_perf/ks9857og
Reviewed By: YousefSalama
Differential Revision: D52836856
fbshipit-source-id: 0388450fd50c76842acb0442771905b23f5898e2
Summary:
Avoid linkifying example URL.
Without wrapping the URL in backticks, Docusaurus will linkify
the URL to point at the actual pull request, making the docs
not clear at all.
Pull Request resolved: https://github.com/facebook/sapling/pull/813
Reviewed By: mitrandir77
Differential Revision: D52769859
fbshipit-source-id: 5a884580613150c058704b0f2364865077f6a40e
Summary:
EdenFs uses the batch size 32. So, it is the most loggical to allow
concurrency up to the same size. Otherwise we just create an artificial 3x slow
down for these requests.
We have other protection like cachelib shards limit, etc, to keep out throuput
bounded, so it doesn't make much sense to configure this number to be 3x
smaller than the EdenFs batch.
https://fburl.com/scuba/mononoke_test_perf/bz3zda7t
We would improve a good amount of fetches.
https://fburl.com/scuba/mononoke_test_perf/8z6kz6le
In case, we would like to set it lower due to some reason, then we would need to lower the eden fs
batch size as well, so that they would go with a smaller batch at a time but to more
hosts concurrently to avoid artificial slow downs when we still have headroom
in throughput. The idea is that optimal performance is reached when these
two values are matched.
Differential Revision: D52833986
fbshipit-source-id: f4dc0b81c7a82b117b851ca38e9c6e84e0aee420
Summary: Turn off animation when the system setting is off.
Reviewed By: evangrayk
Differential Revision: D52812231
fbshipit-source-id: 0320c2a4d573f4c93786926cf30568530c80e3b7
Summary: Update the test to match the latest client-side logic.
Reviewed By: muirdm
Differential Revision: D52814455
fbshipit-source-id: 1de71bb628765c53a60eea8f43e5456dcd251444
Summary:
I notice that when committing, while the optimistic state matches the final
state, the commits below moves up and down unnecessarily.
Upon debugging using a breakpoint in AnimatedReorderGroup when it decides to
animate, I found a 4px animation, and the VSCode buttons [Uncommit] [Split]
were in its "primary" style, with a larger height first rendered. Apparently
the VSCode button then change to the specified "icon" style, with a different
height, but it does not do that in the first render. There are enough pitfalls
in VSCode toolkit we might want to just replace it... but for now let's
workaround the issue by ignoring small distance animation.
Screenshot when hitting the breakpoint - buttons have wrong style and height:
{F1272099178}
Reviewed By: zzl0
Differential Revision: D52667618
fbshipit-source-id: c183d7c60ce0e5da19afd39bf696cff89f5650a3
Summary:
Get animation with just 4-line change!
There are feedback about animation (ex. fading in or out the menu) could
hurt productivity. In this case, it's a sliding, not fading animation, making
it a bit easier to follow what are changed / moved / not changed. So it seems
to provide some value.
With this, for example, it seems to make sense to avoid double "You were here",
"You are moving here" labels, since the moving source is animated to destination.
Reviewed By: muirdm, evangrayk
Differential Revision: D52667620
fbshipit-source-id: e241454ca0d04d4d51ec307b293881ac1e97bba4
Summary: This will be used by upcoming changes.
Reviewed By: muirdm
Differential Revision: D52667619
fbshipit-source-id: cb7375a7a685ef3023495c9e05817be12d95ce05
Summary:
Since "You are here" have a different width, it cannot be followed by edges
like "|". So it must be rendered at the last column.
Reviewed By: muirdm
Differential Revision: D52647445
fbshipit-source-id: ec3531662ca9f41a08f280187a050650dad243f3
Summary:
Initial `<RenderDag />`-based graph rendering, off by default.
An internal config is added to use the new rendering logic:
# render both
sl config --edit isl.experimental-graph-renderer=2
# render new
sl config --edit isl.experimental-graph-renderer=1
Missing pieces:
- "You are moving here" spinner.
- Stack buttons.
- "Load more commits" button.
The selection background does not include the "o" circle because in complex cases
the "o" is not at the right most column, like B, C, D in this graph:
o E
╭─┬─┬─┤
│ o │ │ D
╭─┴─╮ │
│ o │ C
│ ├─╯
o │ B
├───╯
o A
It might make sense to highlight the full row. But that'd be extra changes.
Reviewed By: muirdm, evangrayk
Differential Revision: D52646426
fbshipit-source-id: c568551c242ba94bf25bbeb4f72a5cec9c162c12
Summary:
I notice that:
const img = storage.valueMaybe()?.get(username);
can sometimes return `undefined`, while the `getCachedAvatars` returns the cached map.
I believe the issue is the `async` selector. `async` is always a Promise. By
adopting the `T | Promise<T>` return type we can avoid the flashing.
Reviewed By: evangrayk, zzl0
Differential Revision: D52628411
fbshipit-source-id: 6473019fb4f8865bb3998267244ee3afd42f734b
Summary: Use `align-items: stretch` to better align the button and the select vertically.
Reviewed By: evangrayk, zzl0
Differential Revision: D52628407
fbshipit-source-id: 6b448e9699c700b72d22abc565fd1cb392f0e5ec
Summary:
Port the VSCode font-family and font-size to non-vscode platforms so they look
more similar.
Reviewed By: evangrayk, zzl0
Differential Revision: D52628406
fbshipit-source-id: 83b3bd2167caa3b008ffdcebe0ad7344081139ad
Summary: This will be useful for upcoming changes.
Reviewed By: zzl0
Differential Revision: D52628413
fbshipit-source-id: da47a560771c76703bfcb0d2029b5ea4d6793af5
Summary: Change z-index so it won't be covered by `.changed-file`.
Reviewed By: zzl0
Differential Revision: D52628408
fbshipit-source-id: 605f84e038b954ac4f8270b868ce7e293dced308
Summary:
Add a `bodyOnly = true` mode for `<Commit />`. Once set, skip rendering the
"avatar" and be rendered as part of the `<RenderDag />`.
Reviewed By: zzl0
Differential Revision: D52628409
fbshipit-source-id: d7270edf7c8b4297005d1e27f58d1322af3c3f15
Summary:
The <RenderDag /> takes care of the DAG edge rendering. The callsite can use
callbacks to render individual commits.
There are a lot of follow ups but this gets things going.
Reviewed By: zzl0
Differential Revision: D52546779
fbshipit-source-id: f06e1fc63e004dd40f5e1e28ebc4fa68e8d18b2e
Summary: This will be used by the next change.
Reviewed By: zzl0
Differential Revision: D52628410
fbshipit-source-id: e0b915923201b5f255b1702ba30e1a28cfae43fb
Summary:
Show ancestor edge as:
o
|
:
|
|
o
instead of:
o
:
:
:
:
o
This makes it look more aesthetic in the ISL rendering. It's also easier to layout.
Reviewed By: zzl0
Differential Revision: D52628412
fbshipit-source-id: eaaa5b755f8f9fd198419795d91ff10604c2dda1
Summary:
In ISL, we want to use a different color to draw the "You are here" virtual
commit. The current rendering logic does not yet provide information about
which lines / edges are originated from which commit. For example, in this case:
│ (You are here)
├─╯
o
We want to use a different color to draw these edges:
(You are here)
╭─╯
o
Note the "╭" and the "├" belong to a same `LinkLine` unit so we need to specify
colors for subsets of `LinkLine`s.
This diff changes the diff rendering logic to report:
- What "subsets" of `LinkLine`s are from the commit being rendered.
- What column indexes before (nodeColumn) and after (parentColumns) the link
line are from the commit being rendered.
This will provide enough information for the "You are here" color case, and
potentially other use-cases too. Check the added tests that visualize the
added information.
Reviewed By: muirdm
Differential Revision: D52558936
fbshipit-source-id: 47861e04475288777ace962274a7e19730049a68
Summary:
ISL and CLI use different padding strategies:
o X o X o X
│ ╭─╯ │
╭─╯ │ │
│ │ ╭─╯
o Y o Y o Y
[1] [2] [3]
The CLI uses [2]. ISL uses [3]. Update the renderer to provide padding
at both ends so the callsite can choose which one to use. Note: dashed
lines (ancestor, not direct parents) are only used in the bottom pad
lines.
Reviewed By: evangrayk
Differential Revision: D52558938
fbshipit-source-id: ad31b789b66e065c4e2503262600760414c53832
Summary: This makes the test easier to update.
Reviewed By: evangrayk
Differential Revision: D52558939
fbshipit-source-id: f122a1df3d375ade29efa16e8ca82978251dee12
Summary:
The "You are here" thing can actually be treated as a commit and get involved
into operations. In revsetlang, "You are here" is "wdir()", different from "."
(working parent, or "HEAD" in Git terminology).
By treating "wdir()" as a separate commit in the dag, certain things might make
sense:
- Dragging "wdir()" means "goto", but can have a UX similar to DnD rebase.
- "Combine" "wdir()" with parent means amend.
Related, one selling point of `jj` is that it always treat `wdir()` as a
separate commit.
Reviewed By: evangrayk
Differential Revision: D52546780
fbshipit-source-id: 666b9dbaa7f443b9cb7d5b72b98e28bbb2aa2bb2
