the commit subject in the MR has (MR #) but after the merge, master does not have (MR #) in the commit subject
The merge request has the correct subject: pmaports!5798 (39271954)
The commit on master after the merge doesnt have the correct subject: pmaports@7368bed8
Activity
assigned to @pabloyoyoista
Looking at this, do you by any chance remember the steps you took when merging it? Did you do the regular
mrhlpr checkout number && mrhlpr fixmsg && mrhlpr finish?It honestly looks like a gitlab bug though. If I assume you took those steps, tt seems like:
- You pushed to the remote repository with the amended message
- Gitlab only picked it up in the commits, but not in its main track (see there's no "Anjan added X commits":
- The merge happened when there were no threads unresolved, the source branch was not behind the target branch, and the reviewer had already approved. This means gitlab could merge without waiting for a rebase or checking anything else
- When auto-merge was set, the "push" was still not registered by gitlab, but all conditions to merge where checked. So gitlab just went ahead and merged. The "push" was registered later, but nothing to do, since the MR was already merged
This is a hypothesis. Not sure if this is worth reporting upstream. To fix our problem here, maybe we can force wait some seconds after pushing, to give gitlab some time to process it?
-
I'm pretty sure this is now a change in gitlab's behavior, as this thing happened today to my during my client assignment on gitlab.com . I force-pushed from the terminal, and seconds later clicked merge from the UI. But gitlab had not yet registered the push, and therefore I merged something with a bug, and had to revert afterwards. Not sure how to avoid it ourselves apart from adding some artificial delay?
pmaports!5826 (merged) also has no (MR..) in the commit message