Skip to content
Snippets Groups Projects

MomentumScaling: add the possibility to propagate other parameters to scaling algorithm

Closed Vanya Belyaev requested to merge vanya-momentum-scaling-v1 into master
1 unresolved thread

MomentumScaling: add the possibility to propagate other parameters to scaling algorithm

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
184 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
  • Vanya Belyaev added 1 commit

    added 1 commit

    Compare with previous version

  • Author Developer

    @erodrigu Hi Eduardo, it is fine for me. please put it into 2017. (my knowledge of git is very limited)

  • Vanya Belyaev changed target branch from master to 2017-patches

    changed target branch from master to 2017-patches

  • @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 in master that were merged in master since the last time 2017-patches was merged with master. 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 and master, is to work in your local repository against 2017-patches (so your feature branch is made from 2017-patches) and then make the merge request against 2017-patches.

  • @ibelyaev You cannot just change the target branch in gitlab from master to 2017-patches. The original feature branch your update was applied to was prepared from master, and as such if it is just blindly applied to 2017-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 Jones
  • Christopher Rob Jones changed target branch from 2017-patches to master

    changed target branch from 2017-patches to master

  • rebasing (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/
  • Vanya, by far the simplest thing to do is that you start from 2017-patches, change those files you want and push to 2017-patches. The merge to master can be done later with other MRs.

  • Author Developer

    @rmatev ohhh... it is not so simple :-(
    I'll probably try to restart from scratch, following @erodrigu recipe and submit new MR.

  • @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)

  • closed

  • Please register or sign in to reply
    Loading