"Rebase onto master" button does nothing

Over in issue 2580 I noticed an unrelated problem. In my project's merge request https://gitlab.com/mailman/mailman/merge_requests/48 I see a button that says "Rebase onto master" and describes this as "Fast-forward merge is not possible. Branch must be rebased first".

However, pushing the "Rebase onto master" button appears to have no effect. While it says that the rebase will take some time, reloading the page a few hours later shows that the problem --and button-- persists. There appears to be no way to auto-merge the branch.

I'll attach a screen shot. See the conversation in issue 2580 for more details.

https://gitlab.com/gitlab-org/gitlab-ce/issues/2580

Thanks for creating this issue Barry. /cc @DouweM @dzaporozhets

It seems to be affecting all merge requests, both those that were created before and after the upgrade.

@dzaporozhets can you look into this?

@warsaw just to doublecheck, this is another problem than the one solved in https://gitlab.com/gitlab-org/gitlab-ce/issues/2580#note_2166551 right?

@sytses Yes. I can now see the diff on the Changes tab of the merge requests, but none of them can be auto-merged, even after clicking on Rebase onto master.

@warsaw Thanks! I hope @dzaporozhets will be able to solve this.

@warsaw when you try to rebase this branch locally - does it give you any conflicts?

I too am having this issue, and I can merge the branch locally. Another thing is that, even when GitLab tells me rebase is required, I could merge locally without a rebase.

@dzaporozhets With at least one of the mr's exhibiting this problem, I can merge the branch locally without rebasing, and if I rebase it against master locally, git says that the branch is up-to-date.

Okay, so I just today pushed new branches and submitted new merge requests. Both of these worked just fine and could easily be auto-merged. Maybe this just affects branches submitted before the previous bug? The other interesting data point is that the mr submitter did push some null commits in order to work around the previous bug. Still, the branches merge without conflicts locally.

Yeah, getting this issue as well, on branches that don't need to be rebased. Can merge locally with no problem, and then push to Gitlab as a workaround, but it would be nice to get this fixed, so we can merge from the site as well,

Another thing is that, even when GitLab tells me rebase is required, I could merge locally without a rebase.

Fast-forward merge in GitLab can be done only when target branch is not ahead of source branch. Basically as soon as target branch get new commit after MR was created - you can not perform fast-forward merge. Its true you can merge it locally but it will create merge commit which is different from fast-forward merge.

@dzaporozhets does that mean that if you want to fast-forward you'll have to press the rebase button first?

Don't forget the original report - pushing the rebase button doesn't actually seem to do anything. You get right back to the 'Rebase onto master' button after a short delay.

@dzaporozhets can you respond the @warsaw comment above? how to investigate the rebase button having no effect

does that mean that if you want to fast-forward you'll have to press the rebase button first?

@sytses only if target branch is ahead of source branch. fast-forward merge is merge of source branch into target branch if no new commits were pushed to target branch after source branch was created.

Don't forget the original report - pushing the rebase button doesn't actually seem to do anything. You get right back to the 'Rebase onto master' button after a short delay.

how to investigate the rebase button having no effect

@warsaw The result of rebase is new push. So if you see new commits pushed in merge request discussion - that means that rebase button actually succeed. Otherwise rebase failed. That usually means that it can not be rebased without user attention.

We have planned improvement for rebase feature to show error message if rebase failed. For GitLab team here is internal link - https://dev.gitlab.org/gitlab/gitlab-ee/issues/340

@dzaporozhets Let me see if I understand correctly: When I hit 'Rebase onto master' and reload the page after a while, if I do not see any new commits, then I should assume that the rebase failed. In that case, I should merge manually. Is that correct?

@warsaw That sounds correct to me. Sorry that the error message is not clear. We were in a rush to ship this in 8.0 because it was needed for the satellite deprecation.

We plan to add the warning in 8.2

@sytses No problem, thanks for the confirmation. It was worth it! 8.0 looks beautiful. :)

It was worth it! 8.0 looks beautiful. :)

@warsaw Thank you!

Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/25

Milestone changed to 8.2

@sytses @dzaporozhets @JobV We're getting enough questions about this I think we need to see what we can do sooner. gitlab-org/gitlab-ee#25 seems to have some helpful information on how to reproduce the issue. There may be a bug plus a usability improvement here.

@dblessing it would be great if you could investigate further. I'm worried that it won't move forward otherwise.

For instance, try to replicate the issue.

@dzaporozhets Any updates on this? I can't merge a request (you can see single MR for my projects). What's going on? This perfectly worked for me in github.

This is so basic functionality that it MUST work. Is gitlab in alpha/beta and I should back to github?

@a-paramonov I am confused. Are you talking about rebase feature or merge feature? If you just need ability to merge a request - I recommend you to disable Fast-forward merge feature in your project settings.

@dzaporozhets Thank you, it's what I want to do. But it's really not obvious that by default gitlab uses fast-forward merge (compare to github, of course).

@dzaporozhets The good news is I can finally reproduce this issue on my gitlab-ce fork. The bad news is I see no helpful logs. I will keep trying to find helpful logs but at least we can reproduce.

But it's really not obvious that by default gitlab uses fast-forward merge

@a-paramonov actually it does not. By default it is turned off. Only people who had rebase enabled - get this option enabled too

@dblessing good to know we can reproduce it now.

Added ~12980 label

mentioned in merge request gitlab-recipes!37 (merged)

It should be fixed in 8.2

@vsizov Yes, we also picked this in to 8.1.4 I believe.

Status changed to closed

mentioned in merge request morpheus.lab/morpheus!21 (closed)