Hi Steffen, if I see that correctly this is just a default hook that GitLab does -- offer to open merge requests for each pushed branch. I don't think that fits too well with how we do things: for example, proposing an upstream update via regular merge requests would require all three separate branches to be merged (and MRs to be opened!).
>From my point of view, the merge request mechanism in Debian and GitLab feels more like a replacement or alternative for sending patches: it makes it easy to propagate small, attributable changesets that do not touch more than one branch at a time. Cheers Sascha On 04/27/2018 02:30 PM, Steffen Möller wrote: > Hello, > > does that piece of magic have any particular practial meaning? The > uploads seem to have happened. > > Many thanks > > Steffen > > ~/git/grabix$ git push --all > Counting objects: 27, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (26/26), done. > Writing objects: 100% (27/27), 5.45 KiB | 1.36 MiB/s, done. > Total 27 (delta 13), reused 0 (delta 0) > remote: > remote: To create a merge request for pristine-tar, visit: > remote: > https://salsa.debian.org/med-team/grabix/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar > remote: > remote: To create a merge request for upstream, visit: > remote: > https://salsa.debian.org/med-team/grabix/merge_requests/new?merge_request%5Bsource_branch%5D=upstream > remote: > To salsa.debian.org:med-team/grabix.git > 4ae746a..7ab4f4f master -> master > 1079721..9a1d581 pristine-tar -> pristine-tar > 974be90..4a49cae upstream -> upstream >
