MomentumScaling: add the possibility to propagate other parameters to scaling algorithm
MomentumScaling: add the possibility to propagate other parameters to scaling algorithm
Merge request reports
Activity
Vanya, and there is urgency I see from email exchanges today. So, unless you put this into 2017-patches today/tomorrow, it will go in with 2017 applications as Chris mentions. This is not hugely important but it does make sense to have everyone profit. Then it will be bulk-merged into master soon.
- [2017-07-05 00:02] Validation started with lhcb-old-stripping-tests#455
- [2017-07-05 00:09] Validation started with lhcb-head#1526
- [2017-07-05 00:09] Validation started with lhcb-gaudi-head-noavx#60
- [2017-07-05 00:09] Validation started with lhcb-lcg-dev3#210
- [2017-07-05 00:09] Validation started with lhcb-gaudi-head-noavx2#41
- [2017-07-05 00:10] Validation started with lhcb-gaudi-head#1523
- [2017-07-05 00:10] Validation started with lhcb-clang-test#633
- [2017-07-05 00:10] Validation started with lhcb-lcg-dev4#210
- [2017-07-06 00:03] Validation started with lhcb-old-stripping-tests#456
- [2017-07-06 00:08] Validation started with lhcb-head#1527
- [2017-07-06 00:09] Validation started with lhcb-gaudi-head-noavx2#42
- [2017-07-06 00:09] Validation started with lhcb-clang-test#634
- [2017-07-06 00:09] Validation started with lhcb-gaudi-head-noavx#61
- [2017-07-06 00:09] Validation started with lhcb-lcg-dev3#211
- [2017-07-06 00:09] Validation started with lhcb-gaudi-head#1524
- [2017-07-06 00:10] Validation started with lhcb-lcg-dev4#211
Edited by Software for LHCb184 185 >>> selection = MomentumScaling ( selection , Turbo = 'PersistReco' ) 185 186 """ 186 187 PersistReco = str(Turbo).upper() 187 188 kwargs = {} 189 188 189 if kwargs : kwargs ['PropertiesPrint'] = True @ibelyaev I saw you changed the target branch in gitlab. This has to be done with great care, because by doing so you will pull into
2017-patches
branch any changes inmaster
that were merged inmaster
since the last time2017-patches
was merged withmaster
. If you look in the commits tab above, you will see that you are now picking up 6 commits, which are possibly but not necessarily all harmless. @erodrigu or @rmatev will have to check that this is OK before merging.The recommended way to do this, when you want an MR to apply to both
2017-patches
andmaster
, is to work in your local repository against2017-patches
(so your feature branch is made from2017-patches
) and then make the merge request against2017-patches
.@ibelyaev You cannot just change the target branch in gitlab from
master
to2017-patches
. The original feature branch your update was applied to was prepared frommaster
, and as such if it is just blindly applied to2017-patches
brings in unintended changes. See the commit list. I will change this back to master.You need to think before you prepare a MR where you want it applied to. This is something all developers have to get used to. In this case you need to start a new feature branch from
2017-patches
, make your changes there, and then submit a MR from that branch. We could do this but better you do so you start to get better accustomed to doing this, as we will not do it every time you make an MR.Edited by Christopher Rob Jonesrebasing (with a full project clone and not lb-dev) is a simpler option:
cd $TMPDIR git clone ssh://git@gitlab.cern.ch:7999/lhcb/Phys.git cd Phys git checkout vanya-momentum-scaling-v1 git rebase -i origin/2017-patches # an editor opens. You should keep only the lines with your commits and save git log # make sure the history looks right git push --force # much better to use --force-with-lease, but you might not have it in your git version # see e.g. https://developer.atlassian.com/blog/2015/04/force-with-lease/
@ibelyaev starting from scratch might be simpler in that you avoid getting to know more git, but in the long term I can bet that you'll be much more efficient.
Closing in favour of !147 (merged)