Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Commit Preview #1767
Manual test plan:
User Experience Research (Optional)
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: #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.
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.
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"?
added this to In Progress 🔧
in Feature Sprint : 1 October - 19 November 2018 : v0.21.0
Nov 7, 2018
[Edit]: I fixed the unstaging issue. Now the only thing that is left is the funky rendering.
Found another bug. It appears when the Commit Preview has a mode-change patch with no hunks, and then another patch below it with changed lines:
Unstaging lines throws an error:
Here's the diagnostic output:
Edit: Note that this issue goes away if the mode-change patch is not empty, that is, if it has hunk lines then the alignment and staging is just fine...
And the rendering funkiness seems to correlate with the tiling that the atom text editor does:
Feature Sprint : 1 October - 19 November 2018 : v0.21.0
moved this from In Progress 🔧
to QA Review 🔬
Nov 20, 2018
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!