HTCondorWiki: Managing Condor Source Trees With Git

 $ git branch -d GreatFeature
 {endcode}
 
-{section: Migrating old changes from a previous CVS workspace into GIT}
+{section: Making a single person project into a multiple person project}
 
-During the transition period between CVS and GIT, developers will have CVS workspaces which contain changes that have to be moved over to a git workspace. Currently, the Condor source code CVS repository is frozen and in read only mode. So what you do is this:
+Suppose you have a local topic branch called =bname=. These are the commands you would do to push it into the main repository and allow multiple people to work on it.
 
 {code}
-# Prepare the our code in the CVS workspace we have
-$ cd /old/cvs/workspace
-
-# If your workspace was behind the times, then this will update it to where
-# the CVS repository was frozen.
-$ cvs update
+# First, get it into the main repository
+$ git push origin bname
 
-# resolve any conflicts
+# now rename the local copy to an old version just in case you need it
+$ git branch -m bname-old
 
-# cd to the toplevel (containing config/ src/ imake/ etc.) directory and
-# produce a patch file
-$ cvs -q diff -u >& cdiff
+# Checkout bname from the origin and track it.
+$ git checkout -b bname origin/bname
 
-# edit the top of the patch file to remove any lines denoted with ?
-$ vim ....
-
-# prepare a git repository (as in previous stages in this tutorial) and
-# ensure that you've checked out the corresponding branch as from the workspace
-# you are getting your changes.
-$ git clone /p/condor/repository/CONDOR_SRC.git
-$ git branch <your_branch> origin/<your_branch>
-$ git checkout <your_branch>
-
-# then copy the cdiff file to the toplevel of the git workspace
-$ cp /old/cvs/workspace/cdiff ./CONDOR_SRC
-
-# Then patch the workspace using GNU patch
-$ cd ./CONDOR_SRC
-$ patch -p0 < cdiff
-
-# If any of the patches do not apply cleanly, resolve conflicts.
-
-# At this point check the diffs to ensure you changed what you thought you
-# changed. Do be careful to get this correct.
-$ git diff
-
-# Then commit your changes
-$ git commit -a
-
-# and push
-$ git push
+# Now you can delete the bname-old when you are satisfied bname is in the
+# repository and it is happy.
+# git branch -D bname-old
 {endcode}
 
+*NOTE:* Don't forget to document the branch name in the =CVS_Tags= file!
+
 {section: Working on a project shared with more than one person}
 
 The second most common Condor use case is working with someone else on a shared branch, which happens to be what the stable and development branches are. This might be the most common use case simply because making branches has been complicated in the past.
@@ -360,6 +333,54 @@
 $ git push
 {endcode}
 
+{section: Migrating old changes from a previous CVS workspace into GIT}
+
+During the transition period between CVS and GIT, developers will have CVS workspaces which contain changes that have to be moved over to a git workspace. Currently, the Condor source code CVS repository is frozen and in read only mode. So what you do is this:
+
+{code}
+# Prepare the our code in the CVS workspace we have
+$ cd /old/cvs/workspace
+
+# If your workspace was behind the times, then this will update it to where
+# the CVS repository was frozen.
+$ cvs update
+
+# resolve any conflicts
+
+# cd to the toplevel (containing config/ src/ imake/ etc.) directory and
+# produce a patch file
+$ cvs -q diff -u >& cdiff
+
+# edit the top of the patch file to remove any lines denoted with ?
+$ vim ....
+
+# prepare a git repository (as in previous stages in this tutorial) and
+# ensure that you've checked out the corresponding branch as from the workspace
+# you are getting your changes.
+$ git clone /p/condor/repository/CONDOR_SRC.git
+$ git branch <your_branch> origin/<your_branch>
+$ git checkout <your_branch>
+
+# then copy the cdiff file to the toplevel of the git workspace
+$ cp /old/cvs/workspace/cdiff ./CONDOR_SRC
+
+# Then patch the workspace using GNU patch
+$ cd ./CONDOR_SRC
+$ patch -p0 < cdiff
+
+# If any of the patches do not apply cleanly, resolve conflicts.
+
+# At this point check the diffs to ensure you changed what you thought you
+# changed. Do be careful to get this correct.
+$ git diff
+
+# Then commit your changes
+$ git commit -a
+
+# and push
+$ git push
+{endcode}
+
 {section: Creating a new development or stable series}
 
 The process to create a new development or stable series, i.e. new branches, is just like the process for creating branches for a share project (above). The only difference is how you decide on the branch's name. Instead of using the formula the includes some meaningful name as part of the branch name, you just update the version number.