Encouraged by your reply I looked at it again. Unfortunately it is not easy. Our QMS requires us to have related issue number(s) in every commit subject. There seems to be no way how gitlab would get that/those number(s) into the merge request automatically. It would just be a simple script that can extract them from the commits being merged, but I don't see a way to run such hook.
So we would need to update our process documentation and our CI to allow merge requests without an issue number. And git log —first-parent would become less useful.
This is solved on our end by having the merge not done by gitlab itself (FWIW, github is bad at making these things too) but instead by our robot.
I'm a process wonk, but these checkbox items are still the bane of everyone. It'd be far better if such information were more structured. I'd recommend migrating to git trailers if possible (see `git-interpret-trailers(1)`).
While I'm being shameless anyways, features we have in our robot (for merging):
- renaming the source branch in the message (MRs from `master` is not uncommon)
- treating the target branch as having a different name (so that we can use `refs/heads/release` for "latest release" while future-proofing its merge commit mentions to be `release-X.Y`)
- pulling a block of text from the MR description to add to the merge commit
- putting `+1` comments, reactions, and other review information in the merge commit as `Acked-by: …`, `Reviewed-by: …`, etc.
- merging to multiple branches at once and synchronization (see my prior comment in this thread)
Interesting stuff, thank you. Wasn't aware if this.
Personally I am mostly skeptical of more tools. Some developers have challenges to understand how the basic stuff works. While automation can reduce manual work and mistakes it adds also complexity and adds new points of failure.
Of course there are always exceptions of truly useful tools you don't want to miss. It just depends where to draw the line.
Of course it also depends on the size of the organization and the teams. We have nobody even remotely dedicated to tools, "ordinary" developers maintain them as "side jobs".
It's a tool just like the forge is. I think of these things more as building blocks to put your desired workflow together. I doubt forges will ever handle reformatting, merging, or back porting how we want, so we'll always use something else additionally I think. We could also drop those patterns, but I foresee that meaning we don't have older supported releases instead.
Even this tool is a "side job", but it did have focused development to get it off the ground. We were migrating from a combo of patched Gerrit and gitosis with custom server side commands to implement these things before. In 2015, no forge was even close to having these things, we had to implement it ourselves. Neither Gitlab not GitHub had a good enough API then either, but we could patch and contribute to Gitlab at least. There are other workflow decisions made by Gitlab as well that I prefer too anyways.
