How to handle pull requests with Git Extensions?

Question

I have a public repository on github that I'm having trouble handling pull requests with inside GitExtensions. I've done 3 so far, and I don't think any of them have worked properly or worked where I want them to.

1. On the 19th, I tried to handle a pull request that Yi Jiang created. In GitExtensions, I did a pull within GitExtensions, putting in the remote repository, selecting master as the remote branch, and leaving Merge remote branch to current branch as the default. I clicked Pull and it completed without error. There were a couple of things that I cleaned up, and then I then did a push in GitExtensions. It didn't fill in a commit message, which surprised me, so I just tossed in the URL of Yi Jiang's commit because I didn't know what else to do. The result was that it shows up as a pair of commits, one from Yi Jiang as an author and one from me as an author.

2. Later on the 19th, I tried to handle a pull request that Michael created. Since it seemed pretty clear that I did the first one wrong, I looked for another option. I ran the first set of commands found here, and this does seem to have worked great. The only problem is that I had to do it via the command line rather than within GitExtensions.

3. Another pull request from Yi Jiang. Since doing it via GitBash rather than GitExtensions seemed to work the last time, I tried it again. This time however, it wouldn't complete because there were merge conflicts. Ok, so I go to GitExtensions and do a merge because I know that will let me solve the conflicts. So, I open up the Merge branches dialog and select Merge with and select Yi Jiang's master branch leaving Keep a single branch line if possible (fast forward). I resolve the conflicts and do a push. It automatically put in the commit message for me. This shows up as 4 entries, 3 from Yi Jiang as the author, and 1 from me as the author. Doesn't seem right.

So my question is, how am I supposed to do this properly? I've got another pull request and I want to make sure I am handling it correctly. The fork queue says it won't apply cleanly, so I foresee that I'll need to do a merge. I want to make sure that I am merging properly and that the branches and the commits are being attributed to the people that did the work. If there are edits that need to be done, should I just do the merge/push first and then do a 2nd commit just with the single branch? How does this affect needing to resolve merges?

Could someone walk through the exact process of correctly handling a pull request in GitExtensions?

Answer 1

#1 sounds normal - The first is the commit from the branch you pulled in, the second is the merge commit (that actually merges the branches together). The merge commit is by whoever does the git pull - but if you look at the files in git blame, you'll see that the blame lines are all for the original author (merge commits don't actually add blame lines unless you resolve conflicts).

#3 also seems normal for the same reason - merging adds a single commit that actually merges the branches.

My guess with #2 is that the pull request there actually was a fast-forward, and thus no merge commit was necessary, whereas #1 and #3 were not fast-forward (even if they did merge without conflicts, they weren't direct descendants of the your HEAD).

Basically, I think you're actually doing it right, even if it seems a bit odd. :)

If you want a slightly more length explanation of the differences between fast-forward and merge, here's someone else's words:

On merges and "fast forward"

You'll notice that we've been seeing the phrase "fast forward" several times. This is a special-case operation performed by "git merge" where a branch can be advanced along a linear sequence. This happens whenever you pull changes that build directly on top of the same commit you have as your most recent commit. In other words, there was never any divergence or simultaneous commits created in parallel in multiple repositories. If there had been parallel commits, then "git merge" would actually introduce a new merge commit to tie the two commits together.

When a non-fast-forward merge occurs, there is always the possibility that a conflict occurs. In this case, "git merge" will leave conflict markers in the files and instruct you to resolve the conflicts. When you are finished, you would issue a "git commit -a" to create the merge commit.

(From http://cworth.org/hgbook-git/tour/)

Edit

I went and looked at the actual repository on Github. The last two pulls (#2 and #3) seem to have worked properly, and done what should have been done - fast-forwarding in the case of #2, and merging (with an added merge commit) in #3.

I'm not quite sure what happened with #1 - somehow, it appears, part of the changes got put into a separate commit by you? Couldn't really tell better without having been able to look at what actually was done at the time. Perhaps you had uncommitted changes and you committed them without noticing?