Summary:
Don't crash on the "m" flag used to mark submodules in the manifest.
Also, deprecrate "sl manifest" in favor of "sl files". The "sl manifest --all" flag doesn't work anymore, anyway.
Reviewed By: sggutier
Differential Revision: D44772327
fbshipit-source-id: bad76f0defe95c4a11df9b606e56983583dc5e32
Summary: We offer the `--force` flag with the python implementation, this adds it for the C++ implementation in preparation for migration
Reviewed By: kmancini
Differential Revision: D44473785
fbshipit-source-id: 041613ff0d4048b40b02f7d8f024c78d659516f0
Summary:
Noticed that this was running while looking at a log on Linux. This does nothing on Linux/macOS besides loading inodes (ie: extra overhead), thus disable it.
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: genevievehelsel
Differential Revision: D44835074
fbshipit-source-id: 3b80e4ccf0f63d50de395002c6a8d05a5e99952c
Summary: Fixes a wacky bug with one of our internal tools
Reviewed By: pushpakrajgautam
Differential Revision: D44811936
fbshipit-source-id: f3b6f07ff035c8d535792dec5add5146c1314f36
Summary:
Grammar update:
"eden debugedenimporthelper command command will be sent to this file."
Removed repeated ‘command’
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: chadaustin
Differential Revision: D44799690
fbshipit-source-id: 03e70a8ec300d2b635ea02f9e03802a4f44e9d32
Summary:
We have a force-unmount-all.sh script as a last resort when a Linux
machine has a pile of stuck FUSE mounts.
Introduce a new script that only unmounts the ones under $TMPDIR,
which were probably created by failed integration tests.
Reviewed By: mshroyer
Differential Revision: D44797173
fbshipit-source-id: 41f31cf1e2e57ad07076cf1b2571c739b67b77f0
Summary:
Early iteration on adding the smallcommitmetadata for stables.
Open to naming/design feedback. Just getting it out here first for feedback.
Reviewed By: evangrayk
Differential Revision: D44729878
fbshipit-source-id: fe78c63ca157d79b75892c40855308457b8960ad
Summary: fix clippy warning by using replacing match with if let
Reviewed By: quark-zju
Differential Revision: D44728168
fbshipit-source-id: 27a944267263595ea9367c08f6716a3d2f6820bb
Summary:
we need to check if the path is in the target commit when no rename
commits found, this fixes a bug found in the previous test
Reviewed By: quark-zju
Differential Revision: D44728170
fbshipit-source-id: 7a039b0f9fee80671653e1557b80b218b58f4e99
Summary:
refactor vertex_to_tree_manifest to only process one commit, so it can be used in the following
diff to check if a path is in a commit
Reviewed By: quark-zju
Differential Revision: D44728172
fbshipit-source-id: fc9530b38757d836ca8a5a46e463a5ade510839d
Summary:
this diff adds more unit tests to cover: multiple renames, non-linear
comit graph, deletes.
This diff contain tests catch a bug in the current implementation, which
will be fixed in the following diffs.
Reviewed By: quark-zju
Differential Revision: D44728169
fbshipit-source-id: b0aaeeffa9008a70bbfe3105cceed3afb3d65d45
Summary: Makes it explicitly mention that `sort` method sorts the set in topo descending order, this is different than the `sort` function in revset, which sort the set in ascending order by default.
Reviewed By: quark-zju
Differential Revision: D44728173
fbshipit-source-id: aa95993b237ebacc587147da9caccdf43ff48b80
Summary: Add test utilities for testing copy trace logic, also added a simple test case as an example.
Reviewed By: quark-zju
Differential Revision: D44559585
fbshipit-source-id: b03796fa3869d94edc528d570d511b1d84b15861
Summary:
add vertex_fn parameter to ImportAscii trait, so that we can control
how to generate Vertex from a string: for example HgId expects 20-bytes vertex.
Reviewed By: quark-zju
Differential Revision: D44739947
fbshipit-source-id: c82c95ce4d6c45562c32ad4ccc3e5b40fd517770
Summary:
Commit messages may be very long in the sidebar. This pushes useful info like files changed to an unreasonably far scrolling distance.
Instead, we can show the first bit of each field, and truncate it if it's too long. Then we add a "see more" button which uncollapses the rest of the field.
This requires us to measure the rendered height of the content we're hiding, and determining if we should show the "see more" button or not. It's always slightly annoying to have to deal with measuring DOM heights, here we have to do one extra trick to our useLayoutEffect to ensure we rerender often enough. Otherwise the UI may be too long and get truncated without rendering the "see more" button, which is confusing.
Reviewed By: zzl0
Differential Revision: D44734415
fbshipit-source-id: 06d821ae68fc7d04e00ab4071adf7da2b916beb2
Summary:
Now that we're moving towards dynamic commit message field configs, we should make it easier to define. The "key" value we had here was purely for convenience in typescript, so we could use things like `commitMessageFields.testPlan`. However, since this is dynamic, we can't really do this anyway, so it makes more sense to just unify everything to use the same label value.
So, if we parse a commit message like:
```
my commit
Summary: my summary!
Test Plan: my test plan!
```
Then we would extract this into an object like:
```
{
"Title": "my commit",
"Summary": "my summary!",
"Test Plan": "my test plan!",
}
```
This makes the field config simpler to define.
We may need to add a new field back into this config, which allows for display-only names, which may be useful internally (e.g. we could show "Diff" instead of "Differential Revision").
Reviewed By: muirdm
Differential Revision: D44689896
fbshipit-source-id: c95afd83e06f444cd735302524b589f3cba6a305
Summary:
The field config schema defines which fields we expect in commit messages in this repo, and how the user should interact with them.
Previously, we had the field config schema defined as a global constant, overwritten for internal builds.
instead, we want this to be a fully dynamic value, which could be set by an sl config. This allows repos to configure their own commit message field formats, in case you want to always have a summary/test plan/fixes PR #xyz, etc.
Making this get set in recoil means we can dynamically update this schema and use it for rendering.
Reviewed By: muirdm
Differential Revision: D44688584
fbshipit-source-id: 286b52990266848fce752d980a2849b7fffc60e4
Summary:
like the previous diff, but for parsing from string into commitMessageFields instead of converting into a string.
This uses the logic we use internally (adapted slightly for generality). Again, this is overkill for OSS, where we just take the entire description. Eventually, this will be possibly useful in OSS where you might set this via config.
Reviewed By: muirdm
Differential Revision: D44688587
fbshipit-source-id: 4b4f178283732bf94c137f7ed58c7d8bfaaf027a
Summary: Continue refactoring as in previous diff, now for conversion from commitMessageFields back into a string. This is much more complicated than necessary for OSS right now, because OSS only uses the title and entire description. But soon we'll support arbitrary fields for OSS too, so they'll need this as well.
Reviewed By: muirdm
Differential Revision: D44688586
fbshipit-source-id: e33b4d10e972d556cdc531504b4d66ee36c471c9
Summary: Continue refactoring as in previous diff, now for the various fieldsBeingEdited utils.
Reviewed By: muirdm
Differential Revision: D44688582
fbshipit-source-id: 9f870cfb57d3460f2d469ef929fb077d5ff8deff
Summary:
Context:
Start a set of incremental refactors which will make the CommitMessageFieldsUtils type only contain the field schema, and no other utils. From there, we'll make that field config a recoil atom so it can be determiend completely dynamically by the server / sl config.
This is part 1, where we make `emptyCommitMessageFields` not part of the utils object, and instead just a util function which takes in the config.
Reviewed By: muirdm
Differential Revision: D44688585
fbshipit-source-id: d9ed56fa0975514452ff547bdea58aaaed120653
Summary:
Previous diffs made the types for commit message fields be generic and statically typed, differing between internal and external. We're instead going to go for a completely dynamic field config determined by sl config. This means we should make these types not statically known at all. This diff is the first step in doing this.
Next, we can remove the internal only implementations of utils and make the field config be returned by the server.
Reviewed By: muirdm
Differential Revision: D44688588
fbshipit-source-id: e63d6343596e48a0563975763c438e45d615f5b4
Summary:
After splitting the commit info view into fields, it broke a lot of tests. We need to go fix some of our test utils and some tests themselves.
These tests were extremely useful, I caught at least 5 bugs I hadn't noticed thanks to them, noticeably around edge cases like focus and optimistic state.
Reviewed By: muirdm
Differential Revision: D44648335
fbshipit-source-id: f4e222480f7fba12a55b2f7f6287f3114be73b03
Summary:
After the last diff added fields to the commit info view, there were many bugs remaining, most of which I found while fixing unit tests.
One such bug was that we lost our autofocus behavior which was both now missing and would have been incorrect even if it was kept.
The old behavior focused the description if the title wasn't being edited, and focused the title otherwise.
Instead, we need to go through fields one-by-one down in order until we find one that's being edited. Only that field should be focused.
Reviewed By: muirdm
Differential Revision: D44648086
fbshipit-source-id: 1117cff205f2ab65cdc3a8e9157a8a8f929ca484
Summary:
Change commit info view to render individual fields rather than just one big text box.
Well, at least internally there are differnet fields. In OSS, we don't know what format to use so its still just one big text box.
The idea is that we have a config that defines what fields there are, and what kind. Some are expandable text areas for lots of text, others are one-line fields which will need tokenization and autocomplete etc.
With the fields config, we can render a generic `<CommitInfoViewField>` for each which handles all cases.
Most of the heavy lifting is done by the CommitMessageFieldsUtils (which differs between internal and OSS).
The bulk of this diff is migrating things that previously hardcoded `'title'` and `'description'` fields to now use arbitrary fields.
Note that the design is not final in this diff. This is just rough draft to get something resembling fields. We'll probably do some work to better handle fields with lots of content and better information density for other fields, etc.
{F929608384}
Reviewed By: muirdm
Differential Revision: D44598445
fbshipit-source-id: 195dcc81d7cd6779fd47aa140e6d0c0e94493c48
Summary: In preparation for adding fields to the commit info view, define how internally/externally we define and parse commit message fields.
Reviewed By: muirdm
Differential Revision: D44597627
fbshipit-source-id: f20b6936bff2ea782a3ebb25e1437c61cbad68db
Summary:
Even though we only need the Enumeration in the future's callback, if we don't
move the Enumerator it can get dereferenced while we're awaiting the future
returned by prepareEnumeration().
Reviewed By: xavierd
Differential Revision: D44770398
fbshipit-source-id: a9fc91c0766b4a9f43f566887d714cbde66b1cf3
Summary:
This allows errors to be caught and raised as well as getting file sizes bigger
than off_t which is 32-bits on Windows.
Reviewed By: chadaustin
Differential Revision: D44737139
fbshipit-source-id: 16b00c7f436da361b41ffbe8074958519e9bfc81
Summary:
When the FileInode is materialized, the NonMaterializedState is entirely unused
but still consume memory. On Windows, we've seen cases where the working copy
contains 100k modified files leading to diff taking a really long time due to
EdenFS spending most of its time computing the sha1 of materialized files,
since these are not cached, this computation would be done repeatadly.
For now, this merely creates the scaffolding to enable this caching, future
diffs will move the sha1 and sizes currently stored in the Linux/macOS
OverlayFileAccess in the MaterializedState and care will be taken to invalidate
these on materialization/writes.
For now I've gone with a `union` approach as the existing `Tag` is sufficient
to know which branch of the `union` should be looked at. This is however
potentially error prone, reviewers' opinion on whether I should revamp this and
switch to a `std::variant` would be very welcome.
Reviewed By: chadaustin
Differential Revision: D44652779
fbshipit-source-id: e769f4cc0cd7e8eea0c4cde863cd37f4ceadb01f
Summary:
Tweak revlog commit import to maintain a stable order (this broke after recent change to top sort the commits).
Unfortunately the new stable order is inconsistent w/ fullsegments output in test-eager-exchange.t, so separate the tests.
Reviewed By: quark-zju
Differential Revision: D44768930
fbshipit-source-id: 6757450d7d446373d1b8c943d6cbcc6029b07443
Summary:
This works better with Git. The old filenode-based logic does not seem correct
since it might not trigger adjustlinkrev.
Reviewed By: zzl0
Differential Revision: D44751613
fbshipit-source-id: e5a2367e544f1d55c6a2c149fd33db13af623e46
