Post hacktoberfest was very interesting, I found myself with less and less time to be able to do a lot of the projects needed to be done. This first week was interesting as we were tasked with choosing between 2 options for the next 2 months for contributions (to open source projects). We were to contribute to 2 internal (open source projects started by our peers or supplied by the professor) and 1 external (from anywhere on the internet, better if it was on Github) projects and vice versa for the upcoming month. The order did not matter, so you could do 2 external projects and 1 internal project this month but the next month had to be the opposite.
Given some class time to talk to project leads/maintainers to see what internal projects I could contribute to, I talked to popespaceous (https://github.com/PopeSpaceous/). For a class, he and a group of classmates made a game: Solitary. The project was recently open for development and expansion through Github and is looking for contributors to fill out the basics of a repository. Talking with him, I picked up 2 issues to help him out with. One of the issues was creating a presentable readme with information on how to play the game,how to set up the environment and how to contribute to the project. The other issue I picked up was to contribute more to assets on the project, for example the need for more texture variations to doors. Given how busy I was and the length of the week I was unable to contribute to the project in a pull request.
This week was all about catching up meaningfully. I allocated a large amount of time to creating the readme for the project. I messaged popespaceous for the setup process and was forwarded a very simple list of what to do, he said it needed to be expanded. I went through the setup process and took pictures and documented the specifics I needed to get it up and running.
Recently I switched from typora (https://typora.io/) to visual studio code (https://code.visualstudio.com/) as my markdown editor (use ctrl+shift+v to show a preview of the markdown file). If you have done the same, I would recommend you to keep an eye out on your file syntax. I had spent a lot of time being stuck on simple things like my file had a capitalization at a point and it was not being called when pushed onto my git. Along the lines of that as well, I chose to make poor naming choices for my file calls. Its usually recommended to either name things with underscores between words or use camel case for the naming convention.
After about 2 days of fixing the simple things I had overlooked I pushed my code. I made a pull request and was ready to check the task off my to-do list.
That’s when it happened. A merge conflict was brought up. Over the next 2 days I found what caused the problem, during the fixing process I made, some of my changes in the initial pull request got merged. I created a new branch and continued my work as if nothing happened but the work apparently conflicted with the main branch when I pushed a second time.
Merge conflicts are usually caused by the project being more up to date than the current project on your system. Rebasing is a process to fix merge conflicts and rebasing is downloading the changes and applying all the work you have done to it. The way git does this for you is that whenever you commit to the project it keeps a log of what changed and where. Rebasing uses that log to apply and ask the user if the changes you’ve made should be applied or thrown away compared to whats on the current project.
Dave Humphrey, my professor showed us the basics in class, but I had forgotten the process when it really mattered. I hopped on to the class slack channel and was referred by popespaceous to Sean (https://medium.com/@SeanPrashad) and Stuart (https://stuartcrust.com/) to help out. This man is a life saver and committed a lot of time to help me, hes the best.
One of the things I overlooked when initially set up my project was to set the upstream project to popespacious’. If you have payed attention to the spelling of it you are attentive and I commend you. I spelt his name wrong and set my upstream project to somewhere that doesn’t exist.
Git remote -v to list links to the project fork and the upstream project
Git remote –help in order to see what command to call in order to change the upstream link
git remote set-url upstream upstreamProjectLink to fix the link
I fixed the upstream and pulled the most current work from the repository. Next step was to rebase it. Sean helped me through the process but we were unable to fix it, I kept getting weird errors that amounted to very little or straight up was not in the same vein as what I was experienced when I had searched it up on Google.
Fatal: could not open ‘.git/rebase-apply/final-commit’ for writing: Permission denied
This error was caused because the file was open in visual studio code still or the file was being synced and the file could not be changed.
rm: cannot remove ‘filelocation'”: device or resource busy
We slept on it and came back the next day to Stuart’s message that the file was being used (which in this case I though was weird since I had closed my editor and was unsure what was using the file) could be from file syncing. I generally save my projects on the cloud through dropbox to have access to it wherever I go and it had bitten back at me this time. I paused syncing to the folder where the project was and rebased it, it was quick and painless and it caused me to rethink what I should have synced and where to store school projects.
Finally after you rebase, in order to push your changes, you have to use git push -f branchname, to force the change as git is scared of losing your work.
Overall this week was fairly productive and what I learned the most was to keep an eye on syntax and the small things as they cause a lot of problems when they add up.