I am loving GitHub! Especially the social collaboration that occur around the projects and code. If you never committed code to a OSS project try it – it’s a exhilarating feeling. And just imaging the other side of the coin – to get suggestions and improvements from other people sent to you!
That’s the good news – the bad news (for me at least) is the Git is something else. It’s great but it takes some getting used to. I’m not there yet. For example the preferred way seems to be command line, and I haven’t got used to that yet.
There are some GUIs available that help people like me to overcome the abyss, the most well known is TortoiseGit. That was the tool finally got me to understand, use and love GitHub.
But when I got a pull request sent to me I hit a brick wall. At the bottom of the page for the a pull request in GitHub there are some excellent instructions for how to pull the request into your main branch. But I couldn’t translate that into what to do in TortoiseGit. And that’s one of the problems of a GUI on top of another system – the nomenclature is not always the same and you will run into problems.
So here is ONE way to do it. I’m sure there is another better way but this works.
It took me about 2 hours to find and apply this solution which is enough time for not want to have to do it again.
That’s the good news – the bad news (for me at least) is the Git is something else. It’s great but it takes some getting used to. I’m not there yet. For example the preferred way seems to be command line, and I haven’t got used to that yet.
There are some GUIs available that help people like me to overcome the abyss, the most well known is TortoiseGit. That was the tool finally got me to understand, use and love GitHub.
But when I got a pull request sent to me I hit a brick wall. At the bottom of the page for the a pull request in GitHub there are some excellent instructions for how to pull the request into your main branch. But I couldn’t translate that into what to do in TortoiseGit. And that’s one of the problems of a GUI on top of another system – the nomenclature is not always the same and you will run into problems.
So here is ONE way to do it. I’m sure there is another better way but this works.
- Go to the pull request on GitHub (for example https://github.com/marcusoftnet/KanbanBoards/pull/1)
- Add the extension “.patch” to the URL and download that file to your disk somewhere
- Right-click the folder with your Git local repository (for example C:\Dev\MyProject) and select Git Sync... from TortoiseGit – which opens this window
- From the window select Apply patch
- Choose Add from the next dialog and add the file you save in step 2 above
- Choose Apply
- Now commit the patch to your master
- Optionally push that change to a remote master
It took me about 2 hours to find and apply this solution which is enough time for not want to have to do it again.
3 comments:
Very useful! Thanks! :)
I think it's better to review the patch first: TortoiseGit - Review Patch.
Your solution directly commits the patch to the local repository, creating a lot of reverting actions if the patch turns out to be bad, or needs extra work.
If you 'review' the patch, the files in your working folder are changed, but not yet committed to the local repository.
So you can just revert the changes if needed.
This does not pollute the repository
Thank you Ruben,
great tips.
I have since I wrote this post (a bit upset at the time), restarted and picked up git command line. It took the TekPub videos (http://tekpub.com/productions/git) and two solid weeks of each day practicing but know I got it.
Will not ever go back to a GUI either.
Post a Comment