1

Let's say we have a master branch.

  • I have created a branch2 with no modification
  • I have done a few commits in master
  • Then I noticed that branch2 is a few commits behind master
  • No problem, I just create a pull request master -> branch2, and I merge it
  • Now going on branch2, I expected to see that both are up to date...
  • ...but in fact it shows This branch is 1 commit ahead of master.

Why is it so? Does this mean I can never have both up to date again? It seems I could do an infinite loop: if I now do a PR branch2 -> master (it's possible because branch2 is 1 commit ahead!), and if I merge it, it will be the contrary, master will be 1 commit ahead of branch2.

What's the clean solution to this problem? If possible, from Github UI, and not from git command line.

This problem might be solved with "Fast forward" but it is not a direct duplicate of How to do a fast-forward merge on GitHub? since it seems that there are other solutions, not linked with fast forward, such as this option for GitHub to offer to update branches, as suggested in a comment. Thus this question can be solved by various methods, fast forward is only one of them.

Basj
  • 41,386
  • 99
  • 383
  • 673
  • 3
    Did you look at the history? It's presumably one ahead _by the merge commit_. Maybe you were expecting a fast-forward merge? I'd suggest reading e.g. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github. – jonrsharpe Aug 08 '22 at 21:28
  • @jonrsharpe Yes the *merge commit*, but is there a way to have it in a cleaner way so that it doesn't show this issue? I have done a normal merge from Github UI, can we specify fast-forward or other merging technique? – Basj Aug 08 '22 at 21:29
  • 1
    Note that GitHub doesn't allow fast-forward merges from the web UI. Use `git merge --ff-only ` from the CLI if you want to do a fast-forward merge. – dan1st Aug 08 '22 at 21:29
  • @dan1st Does this mean that from a Github UI merge, there will always have this problem? Does it have other implications that might give problems later? – Basj Aug 08 '22 at 21:30
  • 1
    @dan1st good point, that's called out in the linked docs - even if a local rebase would be able to fast forward, GitHub's _doesn't_. – jonrsharpe Aug 08 '22 at 21:31
  • @dan1st I think you can probably post this as an answer (maybe there is an official doc telling this kind of merge isn't available from Github UI), I'm sure it could be useful for other people too. – Basj Aug 08 '22 at 21:32
  • aside from that, you could just push to the other branch. – dan1st Aug 08 '22 at 21:32
  • @dan1st From command line probably yes, but here I was doing everything from Github UI – Basj Aug 08 '22 at 21:32
  • @dan1st push to the other branch: no because I needed to push this on master, and after this to reflect these changes to branch2 as well. – Basj Aug 08 '22 at 21:34
  • Does this answer your question? [How to do a fast-forward merge on GitHub?](https://stackoverflow.com/questions/60597400/how-to-do-a-fast-forward-merge-on-github) (A fast-forward merge is a merge without a merge commit) – dan1st Aug 08 '22 at 21:35
  • Why a "Need more focus" close vote? The process is described in detail, it is totally reproducible as is. – Basj Aug 08 '22 at 21:35
  • You can also enable an [option for GitHub to offer to update branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches#managing-suggestions-to-update-a-pull-request-branch), and then [pick "rebase"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch#updating-your-pull-request-branch) to avoid extra commits. – Benjamin W. Aug 08 '22 at 21:35
  • @dan1st I don't think it answers the question directly. I mean: when encountering my problem, I would never have thought to search with keywords "fastforward" etc. This linked question+answer is in the case the user already knows the answer is called "fast forward". – Basj Aug 08 '22 at 21:36
  • @BenjaminW. What would this do on this example? Would this make a new option appear when I make the pull request, or when I merge it? What would have happened with this option enabled? – Basj Aug 08 '22 at 21:37
  • I don't think it's a duplicate. There might be other solutions, not linked with Fast forward, such as Pick rebase: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches#managing-suggestions-to-update-a-pull-request-branch, as suggested by @BenjaminW. – Basj Aug 08 '22 at 21:39
  • @Basj While the other questions is about already knowing about the term "fast-forward", this question would still act as a [signpost](https://meta.stackoverflow.com/questions/417601/change-the-stigma-regarding-signposts). And a rebase changes the branch to rebase. A fast forward merge is exactly what was asked _originally_ - a way to do merge without a merge commit (and a fast forward merge doesn't have side effects). – dan1st Aug 08 '22 at 21:40
  • @dan1st Since there are other solutions than fast forward such as BenjaminW.'s comment, this is definitely not a duplicate, and cannot be summarized by "How to do a fast forward", what do you think? – Basj Aug 08 '22 at 21:43
  • @dan1st Then it would be an excellent answer for this question here to make the link between my problem and the term "fast forward"? Your last comment would be a perfect answer. – Basj Aug 08 '22 at 21:45
  • With the option enabled, if you're looking at a PR where the base branch (the branch you're merging into) has received commits since you started the PR, a button to update your branch shows up, and it lets you pick between merging the base branch into your feature branch, of rebase the feature branch on the base branch. – Benjamin W. Aug 09 '22 at 09:28

1 Answers1

0

As mentioned in a comment:

A fast forward merge is exactly what was asked originally - a way to do merge without a merge commit (and a fast forward merge doesn't have side effects): How to do a fast-forward merge on GitHub?

Another solutions is this option for GitHub to offer to update branches and then pick "rebase" to avoid extra commits.

Basj
  • 41,386
  • 99
  • 383
  • 673