Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: #482 when Reset topic clicked it should delete comments too #580
base: main
Are you sure you want to change the base?
Feat: #482 when Reset topic clicked it should delete comments too #580
Changes from all commits
51b9710
d676d85
44653c5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the main cause of the error you're seeing: we want to reset to the initial state except for the initial state's
topic
value, similar to how resetTopicData() is implemented. This is from an unfortunate bit of tech debt 😅 I'm hoping to remove it soon in #581. Essentially if you reset the Topic, we won't know which Topic to make an API request for, preventing the changes from being saved properly.Side note: you also don't need to set
comments: []
here -initialState
has that in it already.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are changes I made in a separate commit - it seems that when you rebased, you removed these changes. This might separately cause problems for you. The easiest way to fix this right now is probably to just manually add these lines back in, and create a fix commit with that.
What I suspect happened is that when you pulled and saw conflicts, you clicked "accept current changes", which kept your changes and removed the changes being pulled in. In this case, you'd have wanted to keep both your changes and the changes being pulled in (generally if you pull changes that someone else made, you probably want to keep them).
To avoid this in the future, it might help to read up on handling merge conflicts and why/how to rebase. Personally, I think Philomatics does a fantastic job of explaining these concepts:
Additionally, I would
fixup
(i.e.squash
without rewording the original commit's message) said fix commit into your original commit, so that your commit only has your changes, and the commit history is a little cleaner. But you don't have tofixup
because I'll handle squashing all commits before merging anyway. If you'd like to look into this, here's another great Philomatics video explaining the interactive rebase, which makes it easy to modify your commit history.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @keyserj , really appreciate you sharing the Philomatics YouTube channel. It was super helpful!
In my last commit, I made a pull request, then committed my changes, and pushed them.
I think you’re right about your note. When I did the pull request, I hit "accept current changes" because I wanted to include my changes, thinking that the other changes would merge in too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting I should edit the git files in the browser or in VSCode and then push it again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One tip I have is to look at the diff between your branch and the upstream after you've resolved conflicts - the diff should only have your changes, not anyone else's (unless you're aware of their changes and intentionally want to change them). You can use a PR to see this diff or use vscode's gitlens extension to compare HEAD (your latest commit on your checked out branch) with
upstream/main
to see the same without a PR, like so:Code_6OHRbZCwXk.mp4
Generally I would make changes locally (via vscode) so that I can test them before pushing anyway (I'm also less familiar with the browser interface). But in either case you'll need to create a new commit for it (or modify the existing commit, but that's not necessary). Also note that if you use the browser, you'll need to remember to pull those changes locally if you do any further local development.