Changes between Version 3 and Version 4 of explainGIT

Timestamp:

Jan 21, 2015, 1:51:25 PM (10 years ago)

Author:

Silvan Scherrer

Comment:

some formating

explainGIT

@@ -11 +11 @@
 And now are the steps for a) (I took the 4.9 branch as an example):
 
+{{{
 git fetch --tags upstream gcc-4_9-branch # download upstream changes (with tags) to our local repo 
 git checkout gcc-4_9-branch # switch to our local branch corresponding to upstream
 git merge upstream/gcc-4_9-branch # merge upstream changes to our local branch
 git push --tags -u origin gcc-4_9-branch # upload all updates we made to our github repo (origin)
+}}}
 
 Note 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).
@@ -24 +26 @@
 Now let’s talk about b) assuming we switch our OS/2 development to a new upstream branch.
 
+{{{
 git checkout -b gcc-4_9-branch-os2 gcc-4_9_2-release # create a new OS/2 branch starting it at the specific tag
 git push -u origin gcc-4_9-branch-os2 # upload the new branch to our github repo (origin)
+}}}
 
 When 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:
 
+{{{
 git push
+}}}
 
 This 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).
@@ -35 +41 @@
 Here are the commands to update the existing OS/2 branch with the new commits from upstream:
 
+{{{
 git checkout gcc-4_9-branch-os2 # switch to the OS/2 branch
 git merge gcc-4_9_2-release # merge upstream changes corresponding to the given tag
         …                                                     # resolve possible conflicts (discussed elsewhere)
 git push # assumes push.default = simple
+}}}
 
 Note 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.
@@ -44 +52 @@
 A tiny hint: If the merge somehow fails and you want to start it over, you may abort the current merge with just:
 
+{{{
 git merge --abort
+}}}
 
 It 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.