0

I started with two commits, A and B, master pointing at A which is older than B, and develop pointing at B. A git log --all --graph --decorate looks like this:

* commit 0af25aa3a4abea9f39ca4da6b7da23cf88546457 (HEAD -> develop, origin/develop) | Date: Thu Aug 27 12:22:23 2020 -0400 | | test | * commit 4ce64615c24e6e69d9afa18364aa2cd460c5ad89 (origin/master, master) | Date: Thu Aug 27 12:12:40 2020 -0400 | | added new paragraph to demonstrate making a commit on a different branch. |

My goal here is to fast forward master so that develop and master are both pointing at commit B. The workflow I wish to do this with is creating a pull request on Github, to merge develop into master, without a merge commit. Just moving the master to point to commit B. When I do a "Rebase and Merge" on Github, instead of just moving the master head to commit B, I end up with this

 * commit 51f368d6aed9d2afae29b374d0ff17245f33f60a (origin/master) | Date: Thu Aug 27 12:22:23 2020 -0400 | | test | | * commit 0af25aa3a4abea9f39ca4da6b7da23cf88546457 (HEAD -> develop, origin/develop) |/ Date: Thu Aug 27 12:22:23 2020 -0400 | | test | * commit 4ce64615c24e6e69d9afa18364aa2cd460c5ad89 (master) | Date: Thu Aug 27 12:12:40 2020 -0400 | | added new paragraph to demonstrate making a commit on a different branch. |

The remote master branch has created a new commit, instead of just pointing to commit B. Is it possible to achieve that with Pull Requests? Or would I potentially have to do the merging locally and then push the fast-forwarded master to remote?

Improve this question

2 Answers 2

Reset to default
2

TL;DR

This is simply what GitHub's "rebase-and-merge" button means. While it does have a strong connection to several underlying Git behaviors, this particular thing—the green "merge" button selection item "rebase and merge", that is—is peculiar to GitHub.

... would I potentially have to do the merging locally and then push the fast-forwarded master to remote?

Sadly (or depending on how you're affected emotionally by GitHub limitations, perhaps annoyingly or something), yes.

Long-ish

As you're probably aware by now, Git itself is really all about commits. Each commit has a unique number, which is its hash ID. The hash ID itself is a cryptographic checksum of the complete contents of the commit, including not only the full snapshot of files that the commit holds, but also the name and email addresses of the author and committer, the date-and-time stamps, and the parent hash ID(s).

In this case, you end up with two commits:

  • 0af25aa3a4abea9f39ca4da6b7da23cf88546457 is your original commit, with you as author and Thu Aug 27 12:22:23 2020 -0400 as author-date. The committer and committer-date probably match these two. The parent of 0af25aa3a4abea9f39ca4da6b7da23cf88546457 is 4ce64615c24e6e69d9afa18364aa2cd460c5ad89.

  • 51f368d6aed9d2afae29b374d0ff17245f33f60a is the copy that GitHub made when you told it to do so, using the green button in the "rebase and merge" mode. The author and author date were retained but the new commit got a new committer and new committer-date, so that, even though the new commit also has parent 4ce64615c24e6e69d9afa18364aa2cd460c5ad89, the new commit's hash ID does not match.

Having copied all the commits that will be "rebase-and-merge"-ed, GitHub then did a fast-forward operation to update their Git's master branch to point to commit 51f368d6aed9d2afae29b374d0ff17245f33f60a. So your own Git's origin/master (after a git fetch) points to this new commit.

This kind of thing happens with a git rebase, because rebase literally can't change any existing commit. Instead, it works by replacing each rebased commit with a new-and-improved version, with a different hash ID. Then, Git changes the branch name to point to the last commit in the new-and-improved chain, instead of pointing to the last commit in the original chain.

Of course, in this case, there was no need to copy the commit in the first place. If GitHub would just not rebase for this case, we'd get a proper fast-forward merge. But they won't.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Thanks for the detailed reply, but I'm a little confused. In the Github docs it literally says "Pull requests with rebased commits are merged using the fast-forward option." but it just isn't happening, is there really no way to do this?
I think this means that if your feature branch is directly ahead of the target branch and you use the "Merge" button (not "Rebase and merge") then GitHub performs a fast-forward merge.
This isn't the case unfortunately. All I want to do is fast forward the master branch to the new commit, but there are only options to create a merge commit (not what I want to do), squash and merge (doesn't fast forward), or rebase and merge (also doesn't fast forward).
The "merge" button always makes a true merge, and the "rebase and merge" variant always copies the commits, even if it doesn't need to. This is one (of several) of the things that annoys me about GitHub. (The "squash and merge" button runs git merge --squash, more or less, and hence is tied much more directly to what command-line Git does.)
If you like having actual merges, the merge button—which is like using git merge --no-ff on the command line—is the right tool, but if you like having fast-forward merges, GitHub have no correct tool.
|
0

I received an answer from the Github forums, stating that

There’s no way to way to fast forward from the web UI. However when you push the fast-forwarded master Github should detect that the commits in the pull request have been merged and mark it as merged.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.