$ git push
{endcode}
-<h1> Checking out an older revision of Condor</h1>
+{section: Checking out an older revision of Condor}
To check out an older revision, suppose Condor 7.1.4, one does this:
-<pre>
+
+{code}
$ # git checkout -b <temporary branch name> <tag name>
$ git checkout -b V7_1_4 V7_1_4
-</pre>
+{endcode}
-The above command creates a temporary branch named V7_1_4 and you will automatically be sitting on that branch. You can now inspect or build the code.
+The above command creates a temporary branch named =V7_1_4= and you will automatically be sitting on that branch. You can now inspect or build the code.
To delete the branch, checkout a different branch, then:
-<pre>
+{code}
$ git branch -D V7_1_4
-</pre>
+{endcode}
-<h1>Adding new externals to CONDOR_EXT.git</h1>
+{section: Adding new externals to CONDOR_EXT.git}
-Adding externals to the git repository is the same as for CVS, described in <a href="https://www.cs.wisc.edu/condor/developers/GENERIC/HOWTO-add-externals.html">HOWTO-add-externals</a>, up to the "Adding it to the appropriate CVS modules" section. Most of the same concepts that existed in the CVS externals repository exist in the git one. The externals are not merged and live primarily on the TRUNK, in git the "master" branch. The difference between the way externals are managed in CVS and in git is how the externals are "branched." In CVS, "branches" were handled as modules in the CVSROOT/modules file, with V7_1_EXT acting as a filter on the full set of externals available in the TRUNK. In git, while all externals should always live on the master branch, subsets of the externals will live on actual branches in the repository, as such the V7_1-branch will be analogous to V7_1_EXT from CVS.
+Adding externals to the git repository is the same as for CVS, described in {link: https://www.cs.wisc.edu/condor/developers/GENERIC/HOWTO-add-externals.html HOWTO-add-externals}, up to the "Adding it to the appropriate CVS modules" section. Most of the same concepts that existed in the CVS externals repository exist in the git one. The externals are not merged and live primarily on the TRUNK, in git the "master" branch. The difference between the way externals are managed in CVS and in git is how the externals are "branched." In CVS, "branches" were handled as modules in the CVSROOT/modules file, with =V7_1_EXT= acting as a filter on the full set of externals available in the TRUNK. In git, while all externals should always live on the master branch, subsets of the externals will live on actual branches in the repository, as such the V7_1-branch will be analogous to =V7_1_EXT= from CVS.
-First, you are going to be committing your new external to the <code>master</code> branch in the CONDOR_EXT.git repository. You'll want to make sure you are on that branch by running <code>git branch</code> and looking for the <code>*</code>. You should go through your normal steps to commit the new external, but you should make an extra effort to commit it all at once. The benefit to committing it all at once is moving the external to a specific branch will be simpler.
+First, you are going to be committing your new external to the =master= branch in the =CONDOR_EXT.git= repository. You'll want to make sure you are on that branch by running =git branch= and looking for the =*=. You should go through your normal steps to commit the new external, but you should make an extra effort to commit it all at once. The benefit to committing it all at once is moving the external to a specific branch will be simpler.
-<pre>
+{code}
# Check to make sure you are on the master branch and that the
# V7_1-branch is avialable
$ git status
@@ -539,11 +540,11 @@
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 externals/bundles/myext/1.0/build_myext-1.0
create mode 100644 externals/bundles/myext/1.0/myext-1.0.tar.gz
-</pre>
+{endcode}
-Second, you want to put your external on either the stable or development branches. This step is analogous to the editing of <code>CVSROOT/modules</code> in the old CVS repository. To do this you will merge the commit you made to the master branch into the V7_1-branch. If you had to make multiple commits to create your external on the master branch then you'll have to do multiple merges.
+Second, you want to put your external on either the stable or development branches. This step is analogous to the editing of =CVSROOT/modules= in the old CVS repository. To do this you will merge the commit you made to the master branch into the =V7_1-branch=. If you had to make multiple commits to create your external on the master branch then you'll have to do multiple merges.
-<pre>
+{code}
# Change over to the V7_1-branch
$ git checkout V7_1-branch
Switched to branch "V7_1-branch"
@@ -555,13 +556,13 @@
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 externals/bundles/myext/1.0/build_myext-1.0
create mode 100644 externals/bundles/myext/1.0/myext-1.0.tar.gz
-</pre>
+{endcode}
That is it. Just like with the CVS externals repository all externals will live on the "TRUNK", and instead of keeping track of externals via a CVS modules file you keep them on branches.
Did you remember to push your changes to the central repository?
-<pre>
+{code}
# Push all your changes to the central repository
$ git push
updating 'refs/heads/V7_1-branch'
@@ -583,11 +584,11 @@
100% (6/6) done
refs/heads/V7_1-branch: 988406a1c51bc089d501563acd7438336a073245 -> 5448f1913bb4486771fa015f83f479b228dc630b
refs/heads/master: 988406a1c51bc089d501563acd7438336a073245 -> 5448f1913bb4486771fa015f83f479b228dc630b
-</pre>
+{endcode}
-If you later need to remove an external you should only do it from the branch that it is used on. There should be no need to remove it from the master branch. Removing it is an <code>rm</code>.
+If you later need to remove an external you should only do it from the branch that it is used on. There should be no need to remove it from the master branch. Removing it is an =rm=.
-<pre>
+{code}
$ git branch
* V7_1-branch
master
@@ -625,11 +626,11 @@
Unpacking 3 objects...
100% (3/3) done
refs/heads/V7_1-branch: 5448f1913bb4486771fa015f83f479b228dc630b -> 984ee883127ab78264d9c5689e82d11371836049
-</pre>
+{endcode}
Oh, life can be even easier if your external was only ever added in a single commit, i.e. you didn't modify it after checking it in. You can simply revert the commit that added your external.
-<pre>
+{code}
$ git revert --no-edit 5448f19
Removed externals/bundles/myext/1.0/build_myext-1.0
Removed externals/bundles/myext/1.0/myext-1.0.tar.gz
@@ -640,6 +641,6 @@
delete mode 100644 externals/bundles/myext/1.0/myext-1.0.tar.gz
$ git push
-</pre>
+{endcode}
Done.
