Why does Rebase and merge always recreate fast-forward commits?

GitHub Help How to use Git and GitHub
#1

Hi,

Having to always git reset --hard origin/master after a PR is merged is the single most annoying thing when using GitHub’s Rebase and merge strategy. The documentation says:

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

…but fails to offer any rationale as for why the committer information needs to be modified.

6 Likes
#2

I don’t get why there’s no fast-forward option (if applicable) either. At least you can avoid it by fast-forward merging locally and pushing, the pull request should recognize that. :slightly_smiling_face:

#3

These are the default settings for each repository, but you can change them in the Settings panel of each repository and enforce the standard Git way of merging PRs or rebasing.

#4

That is true, but you cannot enable fast-forward merging over the web interface, even though that is the default git way of merging when possible.

#5

From what I remember, via those settings you can affect the way pull requests are merged by default, and I remember that recently I asked a project to change those settings to avoid the extra commit when accepting PRs. But I’m not sure about other operations via the WebUI (I only use it for PRs, Issues, and other repository chores, but not to create new commits or other Git related operations).

#6

These are the merge options for one of my repositories. You have a bit of choice what options should be available, but fast-forward unfortunately isn’t one of them.

grafik
grafik795×493 40.8 KB

#7

Yes, your screenshot is correct: you’re looking for “rebase merging” of pull requests, to avoid the extra commit when accepting PRs:

#8

The point of using a fast-forward merge is to avoid rebasing, or otherwise changing the history. I’m well aware that the rebase merge doesn’t create a merge commit, but instead it recreates every commit in between, leading to diverging histories.

My point was simply that there is no ff-merge option in the Github web GUI. Which I consider a flaw, even though it doesn’t really affect me personally because I prefer to merge on the command line anyway.

1 Like
#9

I’m not 100% sure about this, but my guess is that it might have to do with the fact that pull requests are not a native feature of Git, and therefore GitHub arbitrarily chose its own terminology for integrating PRs. On other Git platforms (e.g. GitLab, Bitbucket, etc.) pull requests are named differently (“merge requests”, etc.), which indicates that there’s no unified terminology for PR-related operations.

But I’m curious too about your question, and hope that someone more knowledgeable than me might provide a cut-clear answer on this. Also, the GitHub Help documentation might be improved on this topic, to clarify the issue.

#10

That’s not exactly true, there’s git request-pull, though that’s pretty different from the web UIs of various git hosting services. :wink: Anyway, merging is a native feature, including FF merging, so I don’t see any technical reason not to offer it as an option.

I didn’t actually have a question here, I just stated that the annoying rebase merge behavior can be avoided by FF merging locally. But I’d be curious to hear from Github what’s the rationale for not offering FF merging in the web UI. :slightly_smiling_face:

#11

Wasn’t aware of that. Is this a later-added feature? I always though PRs where an abstraction added by Git hosting services — which, anyway, seem to be partly true, due to the differences in implementation.

Me too. I’m sure there’s some reason why the default behavior was set this way. Possibly it makes sense when merging a multi-commits feature; but then I wonder why the GitHub WebUI is not smart enough to auto-detect single commits PRs and automatically default the PR to rebase modality (which would make more sense IMO).

#12

git request-pull is a pretty old command, it already existed when I
started using git, over 10 years ago by now. It’s mostly used where
people coordinate development over mailing lists, without a shared
hosting service: Push your code to wherever you want, use
request-pull, and send the output to the mailing list so people know
where to get your patches. The most prominent example is probably the
Linux kernel. :wink:

1 Like
#13

I also find this functionality annoying, because I can not merge and continue development in the same branch. As soon as github rebase is realized, the branch used for the PR is unusable. You need to close it and create a new one. That’s a loss of time and resources imho.
And I do not see any reason why this would stay this way. Is it to associate the person who accepted the PR as a co-author of the commits ?

#14

I agree, this is so annoying. Bitbucket does it way better with the explicit fast-forward option.

@statnmap You don’t need to close it, you can run git rebase --onto <new_hash> <old_hash> to update the history of your feature branch to the new commit hashes of master. But yeah, still hella annoying