Difference: LHCbRichMirrorAlignGitInfo (32 vs. 33)

Revision 332018-04-26 - ParasNaik

Line: 1 to 1
 
META TOPICPARENT name="LHCbRichMirrorAlign"
Line: 27 to 27
 The basic idea behind git is that "branches" are used to develop new features of the code, typically each branch forks from the main master branch (the "default" branch) of a git repository, and each new branch is isolated from the other branches, until one chooses to merge them. Typically we use these other branches for development, and then merge them back to the master branch when the new feature is tested and ready. At LHCb we have to ask for a merge request in CERN's GitLab to merge one of our branches into (typically) the master branch of a Project. Then the Project manager can decide whether to allow the merge to occur.

NOTA BENE: However, Panoptes is currently using two main branches. One is called 2018-patches and applies only to 2018 operations, the other is called master and will be used in the upgrade. This significantly changes our workflow:

Changed:
<
<
  • Always lb-checkout out code from 2018-patches and commit any changes to a new branch
  • As usual, set up a merge request when ready to merge the new branch into the 2018-patches branch.
  • NEW Cherry-pick commits from 2018-patches into a second new branch.
  • Set up a merge request when ready to merge the second new branch into the master branch.
>
>
  • ALWAYS lb-checkout out code from 2018-patches and commit any changes to a new branch
  • As usual, set up a merge request when ready to merge the new branch and make CERTAIN that you are merging into the 2018-patches branch.
  • Within the discussion section of the merge request, kindly ask Jordi to rebase these commits into the master branch once the merge request is approved.
    • Jordi will happily do this so long as there are no conflicts. If there is a conflict then you will have to resolve it because "the author knows best".
      • To solve it, you may have to cherry-pick commits from 2018-patches into a second new branch (see below), and then set up a merge request when ready to merge the second new branch into the master branch.
 This seems complicated but it's the only way we can ensure that our changes go into both branches, as the master branch will soon have much code stripped away and changed in favor of the upgrade era code.

Standard documentation and other git stuff

Line: 283 to 285
 

Cherry-picking commits from 2018-patches into master

Changed:
<
<
In the new workflow, we always work with 2018-patches as our starting branch, and we will use 2018-patches as the default branch at the pit as well. However, since for the time being we also want the upgrade code to have all of the changes we made, we are required to manually cherry-pick commits we make to 2018-patches to a new branch, and then merge that new branch into master.
>
>
In the new workflow, we always work with 2018-patches as our starting branch, and we will use 2018-patches as the default branch at the pit as well. Thus make sure that your merge requests are to merge your branch into 2018-patches. However, since for the time being we also want the upgrade code to have all of the changes we made, we are required to either:

1. Rebase the commits that are in your merge request into master

or

2. Manually cherry-pick commits we make to 2018-patches to a new branch, and then merge that new branch into master.

 
Changed:
<
<
There are several ways to do this, which will not be discussed here. However this is something that you have to do, so if you can't figure it out please contact all the mirror alignment experts for advice.
>
>
The former can be done by Jordi as long as there are no merge conflicts (see above on how to request that Jordi do this for you). There are several ways to do the latter, which will not be discussed here. However may be something that you have to do, so if you can't figure it out please contact all the mirror alignment experts for advice.
 

 
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