MQ monitor Psd

added 1 commit

• 83fba2b8 - Apply clang-format

Compare with previous version

assigned to @p.-a.loizeau

approved this merge request

Dear @f.uhlig, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

added 1 commit

• c2550b9c - vector copy removal

Compare with previous version

resolved all threads

added 9 commits

• c2550b9c...35281016 - 6 commits from branch computing:master
• 045d9bce - MQ monitor Psd
• 638262e5 - Apply clang-format
• 11a4e7e9 - vector copy removal

Compare with previous version

enabled an automatic merge when the pipeline for 11a4e7e9 succeeds

canceled the automatic merge

@f.uhlig

Could I merge when ready or do you want to keep the current master clean for another RC patch release?

Should this MR be part of the release? If so, please merge, otherwise I would prefer to merge it only after the release.

I think it can wait

added mCBM label

Dear @karpushkin_AT_inr.ru

As the release is taking more time than we expected, I propose that you merge your branch to the mcbm fork master instead of this main master. For this you would need to perform the following steps:

1. Add mcbm as a remote to your local copy of your branch

   git remote add mcbm git@git.cbm.gsi.de:mcbm/cbmroot.git

   or if you use https access

   git remote add mcbm https://git.cbm.gsi.de/mcbm/cbmroot.git

2. Fetch latest version of the mcbm fork

   git fetch mcbm

3. Rebase against the mcbm master

   git rebase mcbm/master

4. Fix all conflicts (as you have mostly new files, I do not expect that you get too many due to the reformatting of the code-base)
5. Push to your branch
6. Make a new merge request, changing the destination to mcbm/cbmroot:master instead of computing/cbmroot:master

resolved all threads

added 32 commits

• 11a4e7e9...dc524012 - 28 commits from branch computing:master
• dfc4cde2 - MQ monitor Psd
• 6398aea5 - Apply clang-format
• 4a987d83 - vector copy removal
• 27b3a4f7 - conflict resolved

Compare with previous version

mentioned in merge request !323 (merged)

Dear @karpushkin_AT_inr.ru,

It seems the conflict removing during the rebase introduced a merge commit and a loop.

Could you please do the following:

1. Open karpushkin_AT_inr.ru/cbmroot@27b3a4f7 in a browser to have the changes of the "bad" commit as reference to redo them
2. Use the following to remove the last commit:

   git reset --hard HEAD^

3. Re-implement the changes from 1.
4. Re-commit with the same message
5. Force push

   git push --force-with-lease

   • For this to work, you may have to remove the protection of your master branch in Gitlab under Settings (bottom of left menu bar) > Repository > Protected branches
   • I think this protection + Gitlab "features" are the reason why you got the merge commit: after a rebase, one need to use a force push, otherwise Gitlab answers with a message warning that local and remote history are different and asking you to pull first. Do not worry, this happened to many of us at least once, myself included
   • Another setting which may help here is in Settings (bottom of left menu bar) > General > Merge Requests > Merge method to set it as Fast-forward merge instead of Merge commit