May 29, 2022

Generating Github Pull requests

This page is about how to initiate a pull request. I have another page that deals with how to process a pull request you have received.:

I cloned a project, did some work, corresponded with the author, and he requested that I submit my changes back to him as a pull request.

The way to do this properly is to first fork the respository in question. Then create a branch to hold your changes and additions. Commit that to your forked respository, then trigger the pull request. Of course I did not do this at all, I just cloned the repository and started hacking. This means I will have to backtrack, manually merge in the changes I have made, and then I can join the expected process.

Forking a repository

I see forks of repositorys fairly often on Github, and perhaps the desire to create pull requests explains that. I visit the last link above (which is the repository I want to fork). I find that Github has me already logged in. At the upper right is a button marked "Fork", so I click it. I am presented with a dialog page that offers to let me customizet the name of the for. I change it from "mfm" to "mfm_emulator", hoping this won't cause trouble when I go to create a pull request. Then I click the green button "Create Fork".

And it is just that easy. Now I have my own private fork of the MFM emulator in my own Github area.

I could add this point fiddle around to change the remote so my clone is linked to the original repository. This would be a good idea if I expected to be collaborating on the project long term as it would allow me to keep my clone up to date. However in this instance, I expect my contribution to be a one time thing, so don't expect that to be important. The general idea would be to do something like this: 

git remote add --track master upstream https://github.com/dgesswein/mfm.git
git fetch upstream
However, I skip this.

Clone and make branch for the changes

There is nothing new or magic about cloning this newly minted respository onto my home system. I do it using a "git:" URL so that my ssh keys will allow easy access (for me). I already have a directory for my work on this project, and I clone it right alongside (not inside) the copy I have already been working on. 
cd /u1/Projects/Callan/Gesswein
git clone git@github.com:trebisky/mfm_emulator.git
Now I have a choice. Some examples recommend making a branch at this point to hold the changes. Other examples just dive in and make changes to the main branch. Making changes on a branch seems to be the best idea and most commonly recommended. 
cd mfm_emulator
git checkout -b add_callan
 Switched to a new branch 'add_callan'

Make changes

Now some dirty work ensues. I run "make clean" in my originally cloned branch. Then I use "diff -r" to track down which files I changed. 
mfm/mfm_decoder.c
mfm/wd_mfm_decoder.c
mfm/inc/mfm_decoder.h
I copy those files into the new working directory. 
git add .
git commit
git push origin add_callan
(Typing "git push origin master" gives me a the message: "everything up to date message".

This gives me the handy hint: 

remote: Create a pull request for 'add_callan' on GitHub by visiting:
remote:      https://github.com/trebisky/mfm_emulator/pull/new/add_callan
I take note of this suggestion, but just visit my forked repository on the Github web page. It takes me to a dialog to submit the pull request. I fill out a little message for David there and submit the request (which it tells me can be merged without conflicts).

And that is it.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org