Bug fix 1698

[Kaushal-Dhungel]

RE: #1698

I have verified that this pull request:

• has no linting errors (npm run lint)
• is from a uniquely-named feature branch and has been rebased on top of the latest develop branch. (If I was asked to make more changes, I have made sure to rebase onto develop then too)
• is descriptively named and links to an issue number, i.e. Fixes #1698

[welcome]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already.

[catarak]

Thanks for working on this! When I run npm run lint I'm still seeing some warnings—do you think you could fix them in this PR or do you want to open a new PR?

[Kaushal-Dhungel]

I don't know how to fix those warnings in this PR. I think I will create a new PR.

[catarak]

Upon looking at this closely, I think a lot of the changes you made in 47d144a make sense, but a lot of the changes you made in 12259e2 are unrelated to the line length and aren't necessary. In fact, these changes make your PR difficult to review. Would it be possible for you to change stuff that's only coming up in the lint warnings? It seems like you're using another linting configuration to make changes that are unnecessary.

[Kaushal-Dhungel]

This is due to the eslint prettier vscode extension I guess. I will fix that again. Plus there are some " X is assigned a value but never used " warnings. Should I remove them as well?? or are they necessary?? You can see the warnings in the image below:-

[catarak]

That makes sense! Maybe the thing to do here is to add a prettier configuration to the project, which would help out with some of these errors (I believe there's an open issue about this? #1242) I'm happy to help with that.

I do think it makes sense to remove "X is assigned a value but never used"—usually they end up removing dead code.

[Kaushal-Dhungel]

What should I do now?? Should I reformat all the remaining files using prettier eslint and add a config file?? or should I undo my second commit and make changes again without using the prettier eslint extension?? Please guide me.

[catarak]

What should I do now?? Should I reformat all the remaining files using prettier eslint and add a config file?? or should I undo my second commit and make changes again without using the prettier eslint extension?? Please guide me.

I think you should undo the second commit and leave the rest for now. I'm going to investigate setting up prettier with eslint for this project in the very near future since it's been coming up a lot!

[Kaushal-Dhungel]

I spend some hours on the internet but still couldn't find the best way to undo a git commit. I am confused between git reset --hard and git rebase drop. Some suggested not to rewrite the history using git rebase and some suggested not to use git reset as I have to push forcefully. Sorry if I am taking too much time for this simple issue but I am confused once again.

[hydrosquall]

@Kaushal-Dhungel :

• git reset --hard would move the branch's head to whatever commit you were resetting to, which means everything that happens after that commit would be lost.
• git rebase drop would remove the second commit from history, and then apply the commits that happened after (they will have new hashes since history is different, but the code change would be similar assuming they didn't modify the files in the ignored commit)

Both of these options would lead to rewriting history on your branch, and require force pushing. To get some visual intuition about what reset , rebase, and revert would be doing, you may find https://onlywei.github.io/explain-git-with-d3/#revert helpful.

One very safe option if you're still unsure about how to navigate this would be to make a new branch off the latest develop, and cherry-pick just the first commit from this branch onto it. Then you could open a PR from that branch instead.

[Kaushal-Dhungel]

@hydrosquall thank you

[catarak]

Thank you for working on this! Ended up fixing this via #1744 since there hadn't been any updates on here.