Add a planarity notebook

[Arya-Nigam]

I recently submitted a pull request for the Planarity Notebook in the NetworkX repository. I noticed that there are some minor errors in my submission, and I sincerely appreciate your time in reviewing my work.

I am eager to contribute to this project and improve my submission to align with the repository's standards. Please let me know the necessary changes or improvements you'd like me to make, and I'll be happy to update the PR accordingly.

Looking forward to your feedback. Thank you for your guidance and for this opportunity—I’m truly excited to contribute and learn.

Fixes #122

[dschult]

It looks like this PR has a few extra files from isomorphism. These are probably additions you were making to update the Pr to match the main branch. I think it is probably best to "merge" or "rebase" the main branch changes into your branch rather than add them manually through commits and patches to the PR.

To revert the recent commits that caused the problem you can git reset --hard <place to reset HEAD to>. I usually create another branch at the current head in case something goes wrong: git checkout -b new_name then git checkout old_name then git reset....

Then to rebase/merge with the main branch

• make sure you update your local main branch to by pulling from the nx-guides repo.
• checkout the PR branch
• git rebase -i main or if that gets too ugly (too many commits to keep track of which changes go into which commit) then try git merge main.
  • Any conflicting lines will stop the rebase process and git will tell you which files have conflicts. You can then edit the files where the conflicts are marked (search for HEAD). Then you commit those changes and use git rebase --continue to continue to the next set of changes. This is sometimes an onerous task. Ask for help. A merge is easier in the sense that you put all changes together into a single commit so conflicts only have to be managed once for all the commits in your PR. But rebase is better in the sense that the resulting PR has all changes in the most recent commits (merge spreads them out between other commits).
  • You can stop the merge/rebase if you want to start over by using the command git rebase --abort or git merge --abort. The git messages tell you about this too.
• After the rebase or merge successfully finishes you can then push it to your github fork and it automatically updates the PR. This push to your repo will require a git push --force option because it is both removing and adding commits to the remote branch.

There may be places on the web that describe merge/rebase better than I have here. If you have troubles post here and we'll try to figure it out too.

[Arya-Nigam]

It looks like this PR has a few extra files from isomorphism. These are probably additions you were making to update the Pr to match the main branch. I think it is probably best to "merge" or "rebase" the main branch changes into your branch rather than add them manually through commits and patches to the PR.

To revert the recent commits that caused the problem you can git reset --hard <place to reset HEAD to>. I usually create another branch at the current head in case something goes wrong: git checkout -b new_name then git checkout old_name then git reset....

Then to rebase/merge with the main branch

• make sure you update your local main branch to by pulling from the nx-guides repo.

• checkout the PR branch

• git rebase -i main or if that gets too ugly (too many commits to keep track of which changes go into which commit) then try git merge main.

  • Any conflicting lines will stop the rebase process and git will tell you which files have conflicts. You can then edit the files where the conflicts are marked (search for HEAD). Then you commit those changes and use git rebase --continue to continue to the next set of changes. This is sometimes an onerous task. Ask for help. A merge is easier in the sense that you put all changes together into a single commit so conflicts only have to be managed once for all the commits in your PR. But rebase is better in the sense that the resulting PR has all changes in the most recent commits (merge spreads them out between other commits).
  • You can stop the merge/rebase if you want to start over by using the command git rebase --abort or git merge --abort. The git messages tell you about this too.

• After the rebase or merge successfully finishes you can then push it to your github fork and it automatically updates the PR. This push to your repo will require a git push --force option because it is both removing and adding commits to the remote branch.

There may be places on the web that describe merge/rebase better than I have here. If you have troubles post here and we'll try to figure it out too.

Yes, I followed the same procedure by resetting all the previous changes. After adding the planarity section, I merged it with the main branch to retrieve the remaining files. Now, I am at this stage. Please take a moment to review it.