CODEWITHSUNDEEP
gitgithub
Christian Bouwense
Christian Bouwense

Reputation: 165

Rebase and Merge Results in Two Commits with the Same Changes

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?

Upvotes: 0

Views: 210

Answers (2)

Christian Bouwense
Christian Bouwense

Reputation: 165

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.

Upvotes: 0

torek
torek

Reputation: 489828

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.

Upvotes: 2

Related Questions