Question

A project of mine, on GitHub, has been receiving merge requests from another person, lately. This is awesome, but I am being forced to learn how to manage these requests when conflicts arise. The first few merge requests could be automatically merged by GitHub, so I had to do nothing. The latest one has a conflict, because his changes were made and submitted on top of an older commit of mine. I made changes to the repository after he had checked it out, so his is older than mine and cannot be automatically merged.

I'm trying to resolve this by checking out his branch, rebase it to the current local master and then merge it into my local master.

So, I add his repository as a remote. I then try to checkout his repository, but when I look at the code in his repository it does not reflect what I see of his code on GitHub. I just see a clone of my own local master. Here's a pseudo-run-down of what I'm doing:

git remote add person git://path/to/his/repo.git
git checkout -b person/master
git fetch person

After that, I can see his branch when I run git branch -r. His branch is named person/master. I then try git checkout -b person/master. I look at the code in his branch expecting to see his changed code, but I just see my own code. When I look at his person/master branch on his fork on his Github page, I see changes he has made that are not being reflected in my checkout.

What am I doing wrong?

Was it helpful?

Solution

git remote add person git://path/to/his/repo.git
git checkout -b person/master
git fetch person

I would rather fetch first, then checkout:

git remote add person git://path/to/his/repo.git
git fetch person
git checkout -b person/master

But one of the idea behind pull requests is that they should be applied automatically... or "put on hold" ;)
In other words, the contributors ought to do the work for you, then submit an updated pull request for you to apply.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top