Changes between Version 3 and Version 4 of explainGIT


Ignore:
Timestamp:
Jan 21, 2015, 12:51:25 PM (6 years ago)
Author:
Silvan Scherrer
Comment:

some formating

Legend:

Unmodified
Added
Removed
Modified
  • explainGIT

    v3 v4  
    1111And now are the steps for a) (I took the 4.9 branch as an example):
    1212
     13{{{
    1314git fetch --tags upstream gcc-4_9-branch # download upstream changes (with tags) to our local repo
    1415git checkout gcc-4_9-branch # switch to our local branch corresponding to upstream
    1516git merge upstream/gcc-4_9-branch # merge upstream changes to our local branch
    1617git push --tags -u origin gcc-4_9-branch # upload all updates we made to our github repo (origin)
     18}}}
    1719
    1820Note that «our local branch» above doesn’t mean the OS/2 branch. It means a clone of the original upstream branch in our github repo. Since we never modify original upstream branches in our work flow, the merge step will always be a fully automatic fast-forward operation which always applies cleanly and never creates any new commits (or conflicts).
     
    2426Now let’s talk about b) assuming we switch our OS/2 development to a new upstream branch.
    2527
     28{{{
    2629git checkout -b gcc-4_9-branch-os2 gcc-4_9_2-release # create a new OS/2 branch starting it at the specific tag
    2730git push -u origin gcc-4_9-branch-os2 # upload the new branch to our github repo (origin)
     31}}}
    2832
    2933When these steps are done we need to bring all relevant OS/2 changes to the new branch (which may include all OS/2 changes if the new branch originates from some point in history where no OS/2 patches ever existed). This is a big separate discussion, I will write a separate letter on that topic. Let’s omit that for now and assume you somehow merged the changes which you may push with:
    3034
     35{{{
    3136git push
     37}}}
    3238
    3339This assumes ‘push.default’ is set to ‘simple’ so that it will only push the current branch to the linked upstream branch (origin/gcc-4_9-branch-os2 in this case).
     
    3541Here are the commands to update the existing OS/2 branch with the new commits from upstream:
    3642
     43{{{
    3744git checkout gcc-4_9-branch-os2 # switch to the OS/2 branch
    3845git merge gcc-4_9_2-release # merge upstream changes corresponding to the given tag
    3946        …                                                     # resolve possible conflicts (discussed elsewhere)
    4047git push # assumes push.default = simple
     48}}}
    4149
    4250Note that the tag you use in the merge command must mark a point in history of the original upstream branch (gcc-4_9-branch in this case) after the split — i.e. after the commit where the OS/2 branch was started off or last time merged with it. If you specify an unrelated commit, you may create a weird history that doesn’t make any sense from the perspective of our work flow.
     
    4452A tiny hint: If the merge somehow fails and you want to start it over, you may abort the current merge with just:
    4553
     54{{{
    4655git merge --abort
     56}}}
    4757
    4858It should reset the repository to the state it was before issuing the merge command. Note that the abort command will most likely not work correctly if you execute any other git command that modifies the state of files in between.