Commit Preview #1767
Commit Preview #1767
Conversation
There was a problem hiding this comment.
Some questions that might already came up in Slack:
- Should it be a pending pane? It feels like the Commit Preview is something more temporary. Or do people want to keep it open all the time, maybe in a split view?
- Similar and maybe depends on the above, should the Commit Preview pane get automatically closed after committing? Maybe not if there are more unstaged changes since you might want to make a 2nd commit next.
- Should the Commit Preview button be a 3-way toggle? Similar how the Git and GitHub status bar buttons work. If the Commit Preview pane is already open, but not visible (the active tab), users might just want to focus it again, and not close it altogether.
- Should we remove the blinking cursor? And use the default mouse cursor? To not make it look like the diff is editable? Here some options: Editable diffs in FilePatchItems #1720 (comment)
|
addressing @simurai's questions:
@kuychaco brought this up too. I'm not really sure what the difference is between a pending pane and a non pending pane, tbh. I'll learn about that and come back with a more informed opinion.
Yeah, I think we should not close the preview automatically, for that reason.
Is your question prompted by performance concerns? I think the API we're using hides the pane, rather than destroying it.
It depends on when editable diffs are on the roadmap. If we're going to do that soon (like before the end of the year), it might not make sense to implement this. Otherwise yeah, it's confusing if the diff looks like it's editable and it's not. |
Sorry, here a gif that tries to show the issue:
Notice that when clicking on individual files, Atom automatically closes the tab of the previous file. But after opening the "Commit Preview" and clicking on a single file, Atom opens a new tab for that file and keeps the "Commit Preview" tab permanently opened. It's not necessarily a "bug", some people might prefer this behaviour. Ohh.. btw. "pending pane" is a core setting, that can be turned off/on:
More a UX concern. Actually, it now works like a 3-way toggle. 👍👍👍 Just that the label of the button "Close Commit Preview" could be misleading. Example:
Maybe "Close Commit Preview" could be renamed to "Toggle Commit Preview". Then the button label doesn't need to be updated when the "Commit Preview" tab isn't the active tab. Re. button label. I asked about it in our design review. Some felt it's confusing that it says "Commit Preview", because it feels more like a "Show all staged changes". Curious if more people feel that way too.
Ok, I might play around a bit to see if it can be made more "read-only" looking. Anyways, since this PR is our first exploration into multi-file diffs, we don't have to iron out every little detail. 😅 It might be easier to make certain decisions after using this feature for a while. |
Hmm, interesting. I can see your point about "commit preview" being unclear... but I feel like "show all staged changes" doesn't do enough to convey why you want to do that. It's also a bit wordy. Maybe its proximity to the commit editor and commit button will be enough to signal the "why"? |
…atom/commit-preview
Co-Authored-By: Katrina Uychaco <katrina@github.com>
This reverts commit 1acd91e.
test needed to be updated to reflext new getNextSelectionRange logic added in 1685484 Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
… events with no path property Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com> Co-Authored-By: simurai <simurai@users.noreply.github.com>
Co-Authored-By: Tilde Ann Thurium <annthurium@github.com>
There was a problem hiding this comment.
I reviewed all of the application logic changes since my last review, everything looks good!
I also reviewed a bunch of the test files, but eventually decided there are waaaay too many for me to look at and it's probably fine to merge them without looking super closely. They're for insurance, and not as important as the application logic (which can actually contain bugs and regressions). The most important thing around tests is that we have coverage for all new lines, which we do (thanks coveralls!).
Thanks everyone for your fantastic work with this PR! GO TEAM! ✨
|
Good job guys. Congratulacions to all |
🌐 Collaborative pull request to implement the first chunk of behavior described in #1753.
Demo gif
cmd-rightfrom a ChangedFileItem throws an error. Desired behavior should be to focus appropriate file in StagingViewcmd-rightfrom CommitPreview throws an error. Desired behavior is that "Hide All Staged Changes" button is focusedMultiFilePatchmodel that includes an ordered list ofFilePatchobjects.git diffoutput. There may be some tricky work in here in relation to the deleted-symlink-and-created-file and deleted-file-and-created-symlink edge cases. @smashwilsonCommitPreviewcomponent hierarchy for the React side of things:CommitPreviewItemfor the workspace item stuff,CommitPreviewContainerfor the loading and error logic.FilePatchclasses (controller and view) to be usable in both situations, or (b) create new components that are specialized for the multi-file case. I'm leaning a little toward (a) but that might change when we get down into the code. (@annthurium and @kuychaco)CommitViewand the corresponding wiring for the preview action inCommitController.getChangedFilePatchhack and find better way of getting multi file diff inChangedFilesItemPropTypes<>in a file header to open in file takes you to where the selection is, even if it’s not the file corresponding to the headerMetrics
Tests
Unit tests:
For each of these get the test suite to be green and check for missing coverage based on UX testing, application logic, and using coveralls.
Arranged according to component hierarchy. Not in order of what makes sense to tackle first
Test coverage:
Manual test plan:
<>button for file that isn't selectedDocumentation
User Experience Research (Optional)