Difference: Git4LHCb (68 vs. 69)

Revision 692019-07-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"
Line: 208 to 208
 Development: %CODE{"bash"}% #Create environment
Changed:
<
<
lb-dev --nightly-cvmfs --nightly lhcb-head Brunel/HEAD #for a specific nightly add Mon,Tue,Wed,Thu,Fri,Sat,Sun as i.e.: lb-dev --nightly-cvmfs --nightly lhcb-head Mon Brunel/HEAD
>
>
lb-dev --nightly lhcb-head Brunel/HEAD #for a specific nightly add Mon,Tue,Wed,Thu,Fri,Sat,Sun as i.e.: lb-dev --nightly lhcb-head Mon Brunel/HEAD
 cd BrunelDev_HEAD

# Add packages from Rec that you want to modify. e.g.:

Line: 410 to 410
 %ENDCODE% where you replace TheProject and Hat/MyPackage with the correct values (you can use git config -l -f .git-lb-checkout to be sure).
Changed:
<
<

Commit a change to both a patches branch (e.g. 2017-patches) and master

In general, merges to *-patches branches are also merged to the master branch by the project release manager. So just make your merge request to the *-patches branch and it will be propagated for you to master when the MR to *-patches is merged.
>
>

Commit a change to both master and run2-patches branches

master and run2-patches branches are distinct branches for run3 and run1/run2 development respectively. Both branches are in the process of being cleaned up to contain only code relevant for the supported run period, but some of the code is shared. When making a fix or adding a new feature, think whether it is relevant to both branches - if so you should commit it to both. While it is always possible to make distinct commits to the two branches, it is usually cleaner to make the commit to one branch and then cherry-pick it to the other, as this gives a more legible Git history and can avoid merge conflicts in future. Just make the merge request to one of the two branches and make a note in the MR description for the release manager to port to the other branch. Depending on the type of change it may be better to start from one branch rather than the other: for bug fixes, it is usually better to apply first to run2-patches; for new features, apply first to master
 
Changed:
<
<
N.B. if your branch originated from anything other than your target patches branch, you must first "rebase" the branch, see instructions below
>
>
N.B. if your branch originated from anything other than the target branch, you must first "rebase" the branch, see instructions below
 
Changed:
<
<

Commit a change to both master and future branches

In general, merges to master branch are also periodically merged to the future branch by the project release manager. So if you have a change that can apply to both master and future (i.e. it does not require any special features only available in future branch_ just make your merge request to the master branch and it will be propagated for you to future some time later, after the MR to master is merged.

N.B. if your branch originated from anything other than the master branch, you must first "rebase" the branch, see instructions below

>
>

Commit a change to a legacy xxx-patches branch

Legacy branches are intended for maintenance of software versions used in official processings (e.g. a Reco or Stripping version, but also the trigger for a given year). As such, their behaviour should not be modified, so any changes should be considered carefully: it is OK to add new features, but generally not OK to modify algorithms in ways that change their performance, even if it's a bug fix. When propagating a new feature to a (set of) legacy branch(es), it is best to start from the most recent branch (generally, run2-patches) and back port. This is best done by a release manager, just make a note in the MR description of the MR that introduces the change, which legacy branches it should be back-ported to.
 

Rebase a feature branch to a different origin branch

Changed:
<
<
Sometimes you may have been working on a new feature or bug fix in a branch that you created starting from e.g. master, but you wish to make the merge request against another branch, e.g. 2017-patches. Before you push your branch you need to rebase it. In the following example, we assume that you are working on a feature branch called myFeatureBranch in Phys project and wish to rebase it to 2017-patches branch. Proceeed as follows:
>
>
Sometimes you may have been working on a new feature or bug fix in a branch that you created starting from e.g. master, but you wish to make the merge request against another branch, e.g. run2-patches. Before you push your branch you need to rebase it. In the following example, we assume that you are working on a feature branch called myFeatureBranch in Phys project and wish to rebase it to run2-patches branch. Proceeed as follows:
 %CODE{"bash"}% cd $TMPDIR git clone --recurse-submodules ssh://git@gitlab.cern.ch:7999/lhcb/Phys.git cd Phys git checkout myFeatureBranch
Changed:
<
<
git rebase -i origin/2017-patches
>
>
git rebase -i origin/run2-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
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback