desktop: Clicking "Undo" button doesn't populate summary field
Description
I have been using GitHub Desktop for months, and overall I’ve liked it, but something has been acting funny for the last week or two.
Before, whenever I clicked the “Undo” button to undo a commit, the summary and description fields get populated with the description of that commit.
But now, they don’t always get populated. It seems to work for a while, and then stop working, seemingly at random. If I restart GitHub Desktop, it starts working again for a while, then randomly stops again.
Before, I could easily make small changes to my latest commit, like running git commit --amend from the command line. But now, I have to re-type the summary and description, which can be especially annoying if those things are long, or if I simply don’t remember the description I had.
I’d like to see the old behavior, where the inputs are populated every time the “Undo” button is clicked.
Version
- GitHub Desktop: 1.5.0
- Operating system: macOS 10.13.6
Steps to Reproduce
Make a commit, then click the “Undo” button. You may need to try this several times, possibly after GitHub Desktop has been running for several hours.
Expected Behavior
The commit message does not always show in the summary field.
Actual Behavior
The commit message should always show in the summary field.
Logs
I am afraid to attach my log file because it may contain sensitive company information. Sorry. I may try to reproduce this on my home laptop, but I can’t promise that I will have time any time soon, or be able to reproduce it at all.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 24 (14 by maintainers)
Commits related to this issue
- Fix #6390: copy commit message props to state using componentWillReceiveProps — committed to humphd/desktop by humphd 5 years ago
- Fix #6390: copy commit message props to state using componentWillReceiveProps — committed to desktop/desktop by humphd 5 years ago
I spent some time looking into this today, and was able to bisect it back to https://github.com/desktop/desktop/commit/6b9ca6cb7cdc12d6bdda4285874c1d4d813c3e61, which was part of https://github.com/desktop/desktop/pull/6037.
It stems from the way the
propscheck happens incomponentDidUpdate()ofCommitMessage, specifically:When this bug happens, and the commit message
summaryis lost, reference equality for these twopropsObjects is different but value equality is the same. SoshallowEquals()rightly says thatprevProps.commitMessageandthis.props.commitMessageare the same, since the values forsummaryanddescriptionare the same.If I revert this change, the bug is fixed, and even though the state should be the same (values are the same on previous and current), it forces an update, and whatever code that triggers to show the correct value.
I notice in https://github.com/desktop/desktop/pull/6037#discussion_r229748708 @shiftkey suggested the use of
shallowEquals()here to reduce the number ofsetState()calls. I don’t work with react often enough to know what the right fix is, other than this switch back to reference equality. If @shiftkey or @outofambit have suggestions, I’d be willing to finish this. If they’d rather take it over, that’s fine too.Let me know if I can help further. I wanted to do a walkthrough bug fix with my open source students, and picked this one so I could write it up.
I noticed a fix for this bug mentioned in the release notes for 1.6.6. I haven’t seen it since I upgraded a few hours ago. Thanks to whoever fixed it. If I notice it again, I’ll post about it here.
@shiftkey thanks for your encouragement. I’ve opened #6969 based on my diff above.
I’ve finished my walkthrough write-up of this bug to do with my students next week. Sorry I wasn’t able to get it figured out 100%, but I think it will help them learn a bunch of debugging skills regardless.
After my comments above, I also played with another approach to the fix, using
componentWillReceiveProps()to copy the commit message values off ofpropsand into the mirrored internalstate. This also fixes the bug: the summary was cleared internally (state) after the commit, but now it’s copied in again when the repo state changes:I remain unclear on the best way to achieve things in React, so this may be wrong. If it’s close, I’d be happy to open a PR. If not, I’ll probably let someone with more knowledge of the code recommend something.
Your code is fun to work on, and the docs are great.
Thanks @tierninho, based on the above, I’m going to classify this issue as a bug and pri-2. Seems like whomever takes it on will need to do a bit more investigation in how it’s manifesting but seems like there’s enough here to demonstrate a broader issue.