Summary:
A user wants to use a different merge tool for delete+modified conflicts. The current merge tools are not flexible or composable enough to handle this. For example, even if we added a ":delete-keep-local" tool, there is no way to specify the fallback merge tool to use for other kinds of conflicts.
In this diff I introduce a simple DSL to solve the above problem. I called it "merge tool script". It only supports the "if" function, and "isabsent" to test of the "local" or "other" file context is absent/deleted.
Reviewed By: zzl0
Differential Revision: D46163270
fbshipit-source-id: 28f2579e665dc9dd66ab816b10e0b7a758e772f5
Summary: Move string parsing code from revsetlang.py into the parser so other langs can use it.
Reviewed By: zzl0
Differential Revision: D46194125
fbshipit-source-id: cb8c829ceb52a829a831a33b4265410ef704fef9
Summary: v1 and v2 have both been written out forever, so I think we can drop the v1 format.
Reviewed By: zzl0
Differential Revision: D46075828
fbshipit-source-id: 373dae9cf6a53534489022716986aa85b5de5552
Summary: upgrade parking_lot from version 0.11.2 to version 0.12.1
Reviewed By: zertosh, diliop, dtolnay
Differential Revision: D46398501
fbshipit-source-id: ffae0ea188abad5253f1524216dd18ce9a53a74c
Summary:
In D41769964, we decided not to stop `gitimport` simply because `create-bookmark` fails cause that could be due to the fact that the bookmark being created already exists. If that is indeed the case, we try to resolve the bookmark and move it to the new value. However, there could be other unrelated reasons for `create_bookmark` to fail in which case we would still try to resolve the bookmark and end up in unexpected situations (e.g. Luibov trying to import `paws` repo faced this problem). This diff does two things:
- Performs an early check to determine if the bookmark exists by resolving it. If it does exist, it executes the move bookmark branch of code
- If the bookmark doesn't exist, then it creates it.
If there are any errors during bookmark creation or movement, they get logged for the user.
Reviewed By: mitrandir77
Differential Revision: D46071703
fbshipit-source-id: 446b0bc720d13b9e9314feccdb147b2bab0b7cd9
Summary: Added `fill_from_function` which makes it much more useful
Reviewed By: fanzeyi
Differential Revision: D46342378
fbshipit-source-id: 9bc8c01dcb10806a03f1eab628f9763c4e5edc81
Summary:
Our telemetry was showing that starting mid-April the cost of
ObjectStore::getBlobmetadata went down significantly but investigating the root
cause of the improvement didn't seem to yield any results. It turns out the
root cause was that the code no longer timed the cost of the future.
Reviewed By: kmancini
Differential Revision: D46369667
fbshipit-source-id: 0c7d997c93d94498384e27b3447a9c736dcce3b2
Summary:
the previous change broke `test-fb-ext-copytrace.t` tests, but somehow the failure didn't show up in the CI, this is to fix the that.
The issue happened when rebasing 8f852f229 (mv a b) to 046961699 (del a), and file `a` doesn't in the dest commit. The old logic is to keep b in the final commit, and my previous abort with an error that a is not in dest. I think a better way is to report a conflict and ask users to resolve it. But for now, I will keep the old behevior.
```
@ 046961699 72 seconds ago zhaolong
│ del a
│
│ o 8f852f229 107 seconds ago zhaolong
├─╯ mv a b
│
o 7a737d7e6 2 minutes ago zhaolong
╭─╯ add a
```
Reviewed By: sggutier
Differential Revision: D46357844
fbshipit-source-id: f5860c0037b909e2dd1a62700775dba505b88849
Summary: The `lock_env` function from `scm/lib/config/loader/src/test_util.rs` was way too useful to leave in its own crate, since it could be useful for Rust unit tests that modified environment variables
Reviewed By: quark-zju
Differential Revision: D46133861
fbshipit-source-id: b32842c55bd7279490f69601fbb22201da7a0767
Summary: Adds a trait similar to `IOOutput`, which can be used for determining whether the input object held by `IO` is in a tty
Reviewed By: zzl0
Differential Revision: D46129268
fbshipit-source-id: 2fe2b19baf85d6ba361e515cd9e017bda628cc60
Summary: This function will be used in later diffs for determining the default user config file
Reviewed By: muirdm
Differential Revision: D46005612
fbshipit-source-id: 52a0fcba6fbb3d47d24c759d3ff946301ccaa922
Summary:
Currently, the `_forwardcopies` doesn't support git format repo, which
means copytrace can not find the renames on the source side. So let's use
`dagcopytrace` for it as well. It also benefits hg format repos as well, since
`dagcopytrace` support content similarity based rename finder.
Reviewed By: quark-zju
Differential Revision: D46315431
fbshipit-source-id: 5f9ba4a9346f1dbd7e96731b9559dfe686ff028c
Summary:
Currently, the `_forwardcopies` doesn't support git format repo, which
means copytrace can not find the renames on the source side. Add a test to
reproduce this issue.
Reviewed By: quark-zju
Differential Revision: D46315430
fbshipit-source-id: c25f8db6da121a7baa02045720b867c08845f169
Summary:
Both the getBlobMetadata and fetchBlobMetadata were publishing to the same counter, making them indistinguishable.
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: genevievehelsel
Differential Revision: D46343472
fbshipit-source-id: 04e09372c21dd5cb09336259ff34a5394d10d3b4
Summary:
Windows does not support shell scripts.
The code translation is mostly done by ChatGPT.
Reviewed By: evangrayk
Differential Revision: D46334170
fbshipit-source-id: aeca554f364104c49d810a532a6bdf5a55def9ad
Summary:
add new ods logging for bookmark fetching from phases crate
This would help with investigation sevs like S344849, also having this info we
can setup alerts.
Reviewed By: YousefSalama
Differential Revision: D46314640
fbshipit-source-id: 66e72da19ad4eb528c78d0783c297746f57cd4f1
Summary:
I noticed that the scrollbar state or `useState` state in the <Tooltip /> dropdown
does not preserve across state changes. But they preserve fine without <Tooltip />.
I think what happens is, in this function:
function PartialSelectionAction({file}: {file: UIChangedFile}) {
const getPanel = () => {
return <PartialSelectionPanel file={file} />;
};
return (
<Tooltip
component={getPanel}
...>
</Tooltip>
);
}
The `getPanel` is a dynamically created function, and gets used by Tooltip like
`<getPanel ... />`. Then React notices that `getPanel` changes every time per
render (because `getPanel` is not a "static" function) and treat the `getPanel`
as "incompatible" component and re-render the whole thing. Note the `getPanel`
needs the `file` in the closure, so it cannot be a static function.
Fix this issue by avoiding treating `component` as a React component (so React
won't treat it as "component type changed" when re-rendering).
To avoid misuse, I updated `component` signature to no longer be compatible
with a React component. Callsites need to migrate `component={Foo}` to
`component={(dismiss) => <Foo dismiss={dismiss} />}`.
Reviewed By: evangrayk
Differential Revision: D46244645
fbshipit-source-id: 40ea4c0d6637da19ac9fe2b23d9c334e2575a148
Summary:
One of the children in `<Tooltip />` might change without re-rendering `<Tooltip />`.
Trigger `setDimensions` to re-position the tooltip.
Unfortunately this does not prevent rendering the old state. So the user might see
the "wrong" position for a short amount of time.
Reviewed By: evangrayk
Differential Revision: D46188944
fbshipit-source-id: effa41088190ba22929daba0f39beb87f242ef13
Summary:
`useRenderedDimensions` does not recalculate `dimensions` on resize since `ref`
does not change. Fix it by making `children` a dependent.
Reviewed By: evangrayk
Differential Revision: D46188947
fbshipit-source-id: 1edfd8e7eb5515691a8d3672a3afabe004eb695c
Summary:
It seems tooltip is used as a Popover (trigger=click, show `component`) and a
Tooltip (trigger=hover, show `title`). I think it's also useful to work for
both - show tooltip on hover, then show popover on click. This diff implements
that.
Reviewed By: evangrayk
Differential Revision: D46188945
fbshipit-source-id: 30b7f64f5cbca7d031861cbb166dc0ba5c2b8b9c
Summary:
We bump commit date for other operations like amend, rebase, histedit, etc.
Let's do the same for stack editing.
Reviewed By: evangrayk
Differential Revision: D46188950
fbshipit-source-id: 0e636c13f6bd07945c00f5376991e7dcc0a8793a
Summary: This will be used to bump date for the modified commits.
Reviewed By: evangrayk
Differential Revision: D46188949
fbshipit-source-id: 459b5cebf4929343c9442d2d48d8ddf7342a0776
Summary:
It does not make much sense to stack edit a single-commit stack. In the future
if we have split operations then it might make sense to use it. For now let's
just hide the button for a single commit.
Reviewed By: evangrayk
Differential Revision: D46156654
fbshipit-source-id: 553daae9b420ff9bbb500843c36c31977ec04d27
Summary:
Track stack editing sessions: duration, how many times each operation gets
used. For reordering, we also distinguish between DnD reorder and button
reorder.
Reviewed By: zzl0
Differential Revision: D46155621
fbshipit-source-id: f4bc679be2be3c5747a9a7968cac66bc76995afe