Summary: A common naming scheme is to help facilitate finding test directories on machines
Reviewed By: xavierd
Differential Revision: D49040490
fbshipit-source-id: 206e6cb90a65921a38199a04732122ed2952218d
Summary:
The old value `70vh` does not work well with small windows.
Use something like `calc(100vh - 300px)` for a better maxHeight.
Reviewed By: evangrayk
Differential Revision: D49044804
fbshipit-source-id: caecca7e60d851395abf2e04bbb75250fcf56d57
Summary:
Sometimes the "🡆" button overlap with text and is hard to see.
Move the buttons to the line gutters so they won't overlap with text.
Reviewed By: evangrayk
Differential Revision: D49044582
fbshipit-source-id: 2763534a760facb41aa65e06040b94b2fc7b863a
Summary:
Update visual to avoid "too many buttons":
- Moved the split button to the right side, and only show up on hover.
The split button switches tab so it is a bit different from other buttons.
- Simplified elements since we no longer render in the main subtree view.
- Use <CommitTitle /> to render tooltip for full commit message.
Reviewed By: evangrayk
Differential Revision: D49043654
fbshipit-source-id: 655fa293c6e962087bcb82453e0d12e951466a88
Summary:
Features:
- Range split: support splitting a range of commits.
- Text editing: similar to the "Files" tab, the unified diff editors
support text editing.
- Title generation: generate "Split of ..." title by default.
- Title editing: single-line commit title can be edited.
- Single state: state is synced to other stack editing tabs.
For example, you can switch to the "commits" tab, and "fold" commits
while splitting.
Unimplemented considerations:
- Multi-line commit message editing is not allowed.
Message syncing (to internal code review system) can be tricky.
- Side-by-side diff or unified stack modes are disabled.
See the comments in "EditModeSelector" for blockers.
Reviewed By: evangrayk
Differential Revision: D48970674
fbshipit-source-id: 460ed8b66e3d401fbf3ce2814eee1187973dea5a
Summary:
For files that end in newline, the number of newlines is equal to the number of lines.
For files that don't end in new line, the number of newlines plus one for the last line, is equal to the number of lines.
Reviewed By: RajivTS
Differential Revision: D49054968
fbshipit-source-id: 202ab964db39e6bd896582c2b3dde4026ebd2546
Summary:
Original commit changeset: 9a4d9bd3cd65
Original Phabricator Diff: D48796972
D48805908 is the long term fix, revert this to get our test back and to get signal on if D48805908 works
Reviewed By: MichaelCuevas
Differential Revision: D48853050
fbshipit-source-id: eb07498b89e4844db93a839ee991c1ca70fdca44
Summary: This diff includes all the boilerplate code that goes into making a type derivable. Since `GitDeltaManifest` is a `Manifest` type, I have followed the pattern of having a `Root` type (that points to the actual manifest) as the derivable type instead of the core manifest type itself. In this case, the root type is `RootGitDeltaManifestId` which contains the id of the `GitDeltaManifest` for a given commit. The actual logic for deriving `GitDeltaManifest` would be added in the next diff.
Reviewed By: markbt
Differential Revision: D48756522
fbshipit-source-id: 847780f7f51a78bc644c4b6f7791765e3877dd57
Summary: With all the dependencies taken care of, its time to introduce the `GitDeltaManifest` type as a `ShardedMap` type. Most of the code in this diff is `Blobstore` and `Thrift` boilerplate so that we can use `GitDeltaManifest` as a `ShardedMap` type addressed by `GitDeltaManifestId`. The `GitDeltaManifest` blobs would be stored with key `repoxxx.gdm.blake2.{BLAKE2_HASH_OF_COMMIT}`
Reviewed By: markbt
Differential Revision: D48736892
fbshipit-source-id: c364f1e998518650af6f27911748f7f7c192b402
Summary: With the work done so far, we can start introducing the `GitDeltaManifest` type. However, since that type is sharded, this diff just introduces the consistuent types for `GitDeltaManifest` along with their thrift conversions. The types are based on the [design doc](https://docs.google.com/document/d/1mjHNiq1gI-ZwV4ABPBbu6UWIteRvo9SAXxSpq0bINgo/edit?usp=sharing) shared earlier.
Reviewed By: markbt
Differential Revision: D48718190
fbshipit-source-id: fb83383f4ab6b7b09db71550b5f4d6eade9bc5c4
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
