Summary: The third diff in the series of replacing `Option<NonRootMPath>` usages with `MPath`. This is much bigger than the previous diffs because I have updated all manifest type ops and derivation code to use `MPaths` and since pretty much everything in Mononoke uses these types, I had to make a lot of associated changes. After this, I will be updating the `MononokePath` implementation to basically be an alias for `MPath` and making similar changes in `RepoPath`. However, this diff completes the pre-req for doing Git work so further progress might not be immediate.
Reviewed By: markbt
Differential Revision: D49014566
fbshipit-source-id: 0f1d902a6663a73e7fd353a248a91acd06d73bd7
Summary: This is the second diff in the series which replaces usages of `Option<NonRootMPath>` with `MPath`. This diff focuses primarily on `mutable_renames` and `history_traversal`
Differential Revision: D48969972
fbshipit-source-id: c776356822f3d770626dd776a0d4476a8965670a
Summary: This is the first in the series of diffs which replaces the occurences of `Option<NonRootMPath>` with `MPath` wherever appropriate. I aim to restrict these transformations to one component (or related set of components) at a time so its easier to review
Differential Revision: D48966078
fbshipit-source-id: b020c7d22a5dac7d4d7579cf5360e52803aeab56
Summary: The origin `MPath` type was renamed to `NonRootMPath` in the previous diff. This diff introduces the new `MPath` type which can represent both root and non-root paths. It also defines `NonRootMPath` in terms of the new `MPath` so that we can reuse the logic. Note that the same set of methods are implemented for both path types with separate implementations. This is to ensure that the existing use-cases don't break and we can slowly migrate them from `Option<NonRootMPath>` to `MPath` over time
Differential Revision: D48964914
fbshipit-source-id: 75c298f5a52652507ddac52d5b72679572b763de
Summary:
When doing a hack-a-month task I punted on cleaning up some new code to retrieve a simple, human-readable process name - https://www.internalfb.com/diff/D47276991?dst_version_fbid=795860982081651&transaction_fbid=584703497175444.
This change moves the fetching of a simple process name into the process name cache. My first cut at this kept ProcessName and ProcessSimpleName entirely separated in the cache, but the async processing fetched the two together. This felt pretty klunky, so this cut now bundles up ProcessName and ProcessSimpleName along with the pid and ppid (parent pid) into a new struct, ProcessInfo and changes to cache that instead.
In some areas this is more ergonomic and otthers it slightly less ergonomic. The fact we obtain both names and parent pid is overkill in some cases, but what is needed for others. Given that these are used for logging and diagnostics this seemed OK to me.
Note: ProcessSimpleName is only implemented (validly) for macOS today. Adding other platofms should not be difficult, but there is no use case at this time.
Reviewed By: kmancini
Differential Revision: D48923253
fbshipit-source-id: abcbc604e7a319bf1c249cf94948e4ff4b2504c9
Summary: In preparation for merging ProcessSimpleName and ProcessName functionality into ProcessNameCache moving some helper functions to ProcessInfo.
Reviewed By: genevievehelsel
Differential Revision: D48923254
fbshipit-source-id: 9223d45c3b36924750292a302f091fac924ed4cf
Summary: In preparation for merging ProcessSimpleName and ProcessName functionality into ProcessNameCache renaming now The new cache will cache ProcessInfo object which will include both names, and the parent pid.
Reviewed By: genevievehelsel
Differential Revision: D48855222
fbshipit-source-id: 4cb10df7b6cc32efc0d655771d01d58e7ba57dd5
Summary:
the visibilit.remove() function only hides commits if they don't have
any visible descendents. In order to have a more accurate count, let's
check that by checking if visibility.heads() contains the commit.
Reviewed By: quark-zju
Differential Revision: D49013280
fbshipit-source-id: f517ec62354bcda797113ff8c0665f519f584c74
Summary: There has been an "abort if not treestate" in localrepo.dirstate() for a long time, so I think we can kill all non-treestate code paths at this point.
Reviewed By: quark-zju
Differential Revision: D48988900
fbshipit-source-id: b6df9dd3e5ef7a77671099717dd190083542084b
Summary: Add a set of tests for features for the shelved changes list
Reviewed By: quark-zju
Differential Revision: D49018146
fbshipit-source-id: 82ddf739d9893d0d609decce48603080c5e7c33b
Summary: Explain what shelves are. If you've never used them, you might open this dropdown out of curiousity, but find it empty. This tooltip will tell you what they are for and how to add one.
Reviewed By: quark-zju
Differential Revision: D49017220
fbshipit-source-id: e9a5cfc08a3e4412137f372177d7768fe638f6be
Summary: Now the "cache" help topic also includes information about the current cache config.
Reviewed By: sggutier
Differential Revision: D48925373
fbshipit-source-id: e7a00ae303fa978d1955a9040b83e5c2609f7eed
Summary: This has been a hot area recently due to memcache deprecation. Let's try to document how things are configured and how the cache works, briefly.
Reviewed By: sggutier
Differential Revision: D48924185
fbshipit-source-id: c3be77a5553b38c687a7ea5398296508dcdc90fb
Summary: Instead of using an atom to track state for shelved changes, use a promise, which we refresh each time you load the shelved changes list. This way, we fetch a new list of changes each time. It's still possible for the list of shelves to change while the dropdown is open, but I think that's not very common. Perhaps we should refetch periodically while it's open...in the future.
Reviewed By: quark-zju
Differential Revision: D48992198
fbshipit-source-id: abc6f26752948aa7aa68e3c2dade90fe7c24da61
Summary: I noticed the list of shelved changes were ordered by date descending. Let's sort the other way, so if you make a new shelve, it's at the top of the list
Reviewed By: quark-zju
Differential Revision: D48983005
fbshipit-source-id: fad0a7d26b21f02cd53c24f64f8cc3be19b28d60
Summary:
Add operation to run unshelve. The optimistic applier needs to add the same file changes to the list of uncommitted changes, and de-dupe with existing uncommitted changes.
Sort of like uncommit, but slightly simpler because we don't have to change any commits optimistically.
Also use OperationDisabledButton to get a spinner when the operation is running.
I think there's still more work to do on the UI when running unshelve, since we should be hiding the shelve once you've unshelved it.
Reviewed By: quark-zju
Differential Revision: D48982813
fbshipit-source-id: c00646f3fb77a09afa72fca50d2b7e945f921d36
Summary:
Add more functionality to shelved changes list:
- list out changed files in each shelve
- shrink height of scrollable changed files list to just 2.5 files
- add "view changes" button to open comparison view
- add button on hover to unshelve (not implemented yet)
Reviewed By: quark-zju
Differential Revision: D48982811
fbshipit-source-id: a0e9c28dd7ea3741beb207b0f94e3a2003437912
Summary: I noticed when trying to shelve untracked files that it didn't let me by default. We just need to pass `--unknown` to suppor this.
Reviewed By: quark-zju
Differential Revision: D48982807
fbshipit-source-id: b32d271c6b6f4ef8d102081263aac18d4b0a7591
Summary:
Send messages to fetch the shelved changes list and render it in the dropdown.
This is the most basic rendering of the shelved changes, we'll need to add buttons to apply the change and view comparison etc.
Reviewed By: quark-zju
Differential Revision: D48982810
fbshipit-source-id: e18267cb1194a9b20c9f94b4d14fbb0d18b4c0a7
Summary:
Add api to fetch shelved changes, and call to `sl log` that can fetch the info for shelves. This needs to use a different template than the one we use for `CommitInfo`s. We need to fetch additional fields like `{shelvename}`, and we don't need all the fields from `CommitInfo`, like `predecessors`.
I duplicated the way we define the fields for this. There may be a way to consolidate these into a util or something so we don't need any duplication, but I'll put that off until we have yet another format of commit template we need to fetch.
The fetch works because shelves are just commits, and we can use the `shelved()` revset to find them all.
Reviewed By: quark-zju
Differential Revision: D48982809
fbshipit-source-id: 9e2e9fdf946794bace01dc7d95958032acfc37ef
Summary:
Add menu to top bar to show shelved changes.
Debatable whether this is worth a top bar button, since it ONLY shows shelved changes and nothing else. Perhaps in the future we could hide this if you have no shelved changes...?
We can't put it into the uncommitted changes list because you may want to unshelve when you have no changed files (hence the list of uncommitted changes + actions wouldn't appear)
Reviewed By: quark-zju
Differential Revision: D48982808
fbshipit-source-id: 2d3fbbca3f9e924acb35b04b59464300254b1835
Summary:
Add a button to shelve your changes. `sl shelve` removes your uncommitted changes but saves them to a temporary place that you can recover later.
We'll need to also add an unshelve button/list to match, but this diff focuses on the shelve button first. I think the unshelve button will be some top-level thing, since you may not have the uncommitted changes list visible when you'd like to unshelve.
Eventually, we should also add some keyboard shortcuts to shelve/unshelve. That would be so cool!
Several behaviors are packed in here:
- if you've written a title in the quick commit form, it'll use that as your shelved changes' name. This helps when unshelving later, if you have multiple shelved changes.
- if you have a partial selection, it should only use your selected files
- we don't support per-line selections (this would require changes to debugimportstack)
- we use optimistic state to to hide selected file changes while shelve runs
- we disable the shelve button if you don't have anything selected, or if it's a partial selection
- untracked files are shelvable (we get this for free)
Reviewed By: quark-zju
Differential Revision: D48851127
fbshipit-source-id: 7560060be8106fff7a819ae0455c6800dd8ffc66
Summary:
rust-clippy output: {P821184100}
I'm fixing unnecessary hashes around literal strings, unnecessary .into_iter and unnecessary vec!
Remaining are `immediate unwraps on Some`, `&-masking with zero`, `incorrect implementation of clone on a Copy type`, `private item shadows public glob re-export`.
`&-masking with zero` comes from third-party macro expansion, same as one `unnecessary vec!`.
Reviewed By: YousefSalama
Differential Revision: D49014408
fbshipit-source-id: 410c8b831b87eea92a15e012656ed4c1d061fb75
Summary:
this supports to read merge related commit hashes from file, we will
use it to run benchmark on the shallow (lazy) prod repo
Reviewed By: quark-zju
Differential Revision: D48876698
fbshipit-source-id: 836064b8b80699e5d7366944fb18962771ca4fe4
Summary: When we log a redacted access, also log what the reason was and whether or not we enforced it. This will make it easier to check new redactions are being applied correctly.
Differential Revision: D49008130
fbshipit-source-id: 756a65b0756f48731017e7f8b64dfb487e0e2991
Summary:
Detect file status change using `status` timestamp,
and kick off a new fetch in background.
Reviewed By: evangrayk
Differential Revision: D48970663
fbshipit-source-id: 0ed994ee7e875917eaaccf43d4807ff5f25267f8
Summary:
After a partial commit/amend/discard, the "partial selection" state for files
should be invalidated. Alternatively we need to reload the file contents from
disk.
For now, let's just invalidate those "partial selection" files.
Reviewed By: evangrayk
Differential Revision: D48970664
fbshipit-source-id: dbf4074ba0f8f42822247258fbb518d3b04ad006
Summary:
The tooltip is hard to layout:
{F1083502634}
Showing the chunk selections inline so we don't
have to worry much about the height.
Right now only the unified diff view is used. There is no editing or expansion.
This UI seems straightforward to understand.
I thought about switching the tooltip to a modal before. But that is annoying,
for example, the modal has to duplicate operations like commit/amend/discard to
avoid the "double confirm" issue. There is no way to use the right panel for
structured commit message editing. By showing the chunk selector inline we avoid
button duplication and support reusing the right panel.
Reviewed By: evangrayk
Differential Revision: D48970672
fbshipit-source-id: a08b8d57077d3a5dc9c13fd409b8f3c04dcbdddb
Summary: The next change uses this feature to "expand" and "collapse" chunk selections.
Reviewed By: evangrayk
Differential Revision: D48970661
fbshipit-source-id: a27ec31f62fe8c25afadbdc8b43681cd536983fb
Summary:
`FileStackEditPanel` requires the optional file stacks to be built.
While it is often built, with the upcoming split UI it might be not
(after `applySubStak`, for performance reasons). Let's build them
on demand explicitly.
Reviewed By: evangrayk
Differential Revision: D48970667
fbshipit-source-id: a67bbc736f211374b521e3d20c201edaf6f90c61
Summary: A dialog should be above the progress container.
Reviewed By: evangrayk
Differential Revision: D48970665
fbshipit-source-id: a7ce8e9054cad4f7d0ca1805464291a8cbe166d9
Summary:
This makes it slightly easier to use. The interactive split UI does not want
the editors to render commit titles, and always wants to skip only rev 0.
Reviewed By: evangrayk
Differential Revision: D48970673
fbshipit-source-id: 8c095dde3534df38ab1ea7c55a02827bae82d0fd
Summary:
By defining a width, we avoid "width based on text" which is ugly when 2
editors are drawn vertically:
|Editor 1 |
|<---width----->|
| |
|Editor 2 |
|<---width-->|
| |
Now both editors will have the same width:
|Editor 1 |
|<---width----->|
| |
|Editor 2 |
|<---width----->|
| |
Reviewed By: evangrayk
Differential Revision: D48970671
fbshipit-source-id: fcd9377697703a9a5f0b88684e0aa2742dd13f1d
