Instead of merging, this attempts to insert the changes you pull from the origin repository before your local changes, avoiding the merge message. You need to be sure to rebase on the proper branch. For instance, if you are on your =V7_0-branch= and want to rebase against changes in =origin/V7_0-branch= you issue =git rebase origin/V7_0-branch=.
-<h1>Working on a single person project</h1>
+{section: Working on a single person project}
The most common Condor use case is working on a feature all by yourself. We can easily share this work later with others if need be, so don't worry about whether to choose this approach or the team approach described later.
-First, you'll want to make a branch for this work, so you'll need to decide where to branch from, either the development or stable series. Let's say that you want to branch from the 7.0 branch, named V7_0-branch. You'll need to name the branch, too. This is a local name, so you need not worry about name collisions. Let's call the branch GreatFeature. For historical reasons (cough CVS), all of our released branches end in -branch, but there's no need to keep that convention for local branches.
+First, you'll want to make a branch for this work, so you'll need to decide where to branch from, either the development or stable series. Let's say that you want to branch from the 7.0 branch, named =V7_0-branch=. You'll need to name the branch, too. This is a local name, so you need not worry about name collisions. Let's call the branch GreatFeature. For historical reasons (cough CVS), all of our released branches end in -branch, but there's no need to keep that convention for local branches.
-<pre>
+{code}
# Checkout your local 7.0 branch, the one that tracks the central
# repo's V7_0-branch, and merge in all the latest changes from the
# central repository. The "git pull" is analogous to a "cvs update".
@@ -218,13 +218,13 @@
# The -d means validate that the branch was merged fully into HEAD.
$ git branch -d GreatFeature
-</pre>
+{endcode}
-<h1>Migrating old changes from a previous CVS workspace into GIT</h1>
+{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:
-<pre>
+{code}
# Prepare the our code in the CVS workspace we have
$ cd /old/cvs/workspace
@@ -266,31 +266,27 @@
# and push
$ git push
+{endcode}
-
-</pre>
-
-<h1>Working on a project shared with more than one person</h1>
+{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.
-<p>
If you are going to be using a shared branch that already exists you can skip the branch setup steps and move right on to the steps for working on the branch, which are amazingly similar to what you do when working on your own local branch.
-<h3>Decide on a branch name</h3>
+{subsection: Decide on a branch name}
First, decide on a name for your branch, such that XXX describes the newness. If you want XXX to contain multiple words, separate them with underscores, not hyphens. Follow this structure:
-<pre>
+{code}
[new-branch-name] == [old-branch-name without "-branch"]-XXX-branch
-</pre>
+{endcode}
For example, a branch off of V6_5-branch for Paolo might be: "V6_5-paolo-branch". Something more complex would be: "V6_5-gridmanager_reorg-branch"
-<p>
Release branches are made for every release of Condor when we're almost ready to ship them. They should be named with the version of Condor they hold, for example: "V6_5_3-branch". We know that any branch name with a 3-number version like that is a release branch for that specific version.
-<pre>
+{code}
# Lets decide on the name "V7_1-GreatFeature-branch". This means we
# are going to branch from the end of V7_1-branch, so you should make
# sure it is known to build on all platforms and pass all tests.
@@ -305,13 +301,13 @@
# pull" won't get other peoples changes to the branch. Let's fix that
# by recreating the local branch so that it tracks the central branch
$ git branch -f V7_1-GreatFeature-branch origin/V7_1-GreatFeature-branch
-</pre>
+{endcode}
-<h3>Document your branch</h3>
+{subsection: Document your branch}
-Second, you should document your tags in src/CVS_Tags. The manual is going to be branched along with the source so there should be no need to document anything in doc/CVS_Tags anymore. Follow the CVS HOWTO-branch instructions for documenting your new tag:
+Second, you should document your tags in =src/CVS_Tags=. The manual is going to be branched along with the source so there should be no need to document anything in =doc/CVS_Tags= anymore. Follow the CVS HOWTO-branch instructions for documenting your new tag:
-<pre>
+{verbatim}
You *MUST* add a description of the new branch to the src/CVS_Tags
file in the *parent* branch (where the new branch came from).
@@ -320,13 +316,13 @@
merged back into (if we know them). Once you make your changes,
run "git commit src/CVS_Tags" and "git push" as usual to commit
src/CVS_Tags.
-</pre>
+{endverbatim}
-<h3>Update the version string</h3>
+{subsection: Update the version string}
-Third, and finally, you should fix the version string on your new branch. You do this by editing src/condor_c++_util/condor_version.C on your new branch. The exact version you decide on is up to you, but as always you should only change the "comment" portion of he version string, i.e. anything after <code>__DATE__</code> and before <code>$</code>. For example, if the old version string (on the V6_5-branch) looked something like <code>static char* CondorVersionString = "$CondorVersion: 6.5.3 " __DATE__ " $";</code> you might choose <code>static char* CondorVersionString = "$CondorVersion: 6.5.3 " __DATE__ " PRE-RELEASE-UWCS $";</code>.
+Third, and finally, you should fix the version string on your new branch. You do this by editing =src/condor_c++_util/condor_version.C= on your new branch. The exact version you decide on is up to you, but as always you should only change the "comment" portion of he version string, i.e. anything after =__DATE__= and before =$=. For example, if the old version string (on the V6_5-branch) looked something like =static char* CondorVersionString = "$CondorVersion: 6.5.3 " __DATE__ " $";= you might choose =static char* CondorVersionString = "$CondorVersion: 6.5.3 " __DATE__ " PRE-RELEASE-UWCS $";=.
-<pre>
+{code}
# Checkout the new branch
$ git checkout V7_1-GreatFeature-branch
@@ -335,13 +331,13 @@
# Commit your change
$ git commit src/condor_c++_util/condor_version.C
$ git push
-</pre>
+{endcode}
-<h3>Get working</h3>
+{subsection: Get working}
At this point you can go hog wild on the branch:
-<pre>
+{code}
# Hack hack hack
# Commit your changes, these only go to your local copy of the branch
@@ -362,44 +358,42 @@
# Push your changes to the central repo
$ git push
-</pre>
+{endcode}
-<h1>Creating a new development or stable series</h1>
+{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.
-<h1>Merging code from the stable branch to the development branch</h1>
+{section: Merging code from the stable branch to the development branch}
Merging is a very common operation with git, and should be something that you end up doing fairly often. It is not something that you should be wary of. The steps for merging the stable branch into the development branch are essentially the same as for merging any two branches together, except it is likely one of the few times where you may run into conflicts.
-<p>
-To start out, be sure you have a copy of both the development branch and stable branch in your repository, steps for creating them are in <i>Preliminary setup</i>. The next thing you want to do is make sure you have the most recent copies of the branches you are tracking from the central repository.
+To start out, be sure you have a copy of both the development branch and stable branch in your repository, steps for creating them are in _Preliminary setup_. The next thing you want to do is make sure you have the most recent copies of the branches you are tracking from the central repository.
-<pre>
+{code}
# Fetch all updates for the stable, development and any other branches you are tracking from the central repository
$ git fetch
-</pre>
+{endcode}
-Once <code>git fetch</code> finishes you want to checkout the branch you are merging to, which in this case is the development branch.
+Once =git fetch= finishes you want to checkout the branch you are merging to, which in this case is the development branch.
-<pre>
+{code}
# Checkout the development branch, it is the destination of the merge
$ git checkout master
-</pre>
+{endcode}
Before proceeding be sure that you do not have any uncommitted changes on the master. If there are changes either copy them to a separate branch for the time being (to be described sometime) or push them to the central repository. Generally, you will not be developing much on master anyway. You will probably do development on a feature branch, which you merge into the master and push to the central repository.
-<p>
Git has a number of merging algorithms, but, generally, we do not care about any except the default algorithm. There are numerous resources online and git manual pages that explain the different approaches, but the default is more than enough for us.
-<pre>
+{code}
# Perform a merge of V7_0-branch into master, remember we're on the master
$ git merge V7_0-branch
-</pre>
+{endcode}
-Often the merge will have no conflicts, but lets go over what you need to do when you end up with conflicts. First, some much needed background about how git works. When you have a branch checked out in your workspace git maintains what it calls an <i>index</i>. The index is essentially a record of what will go into the next commit you make. You can think of it as a record of what you have changed in a workspace, including added and removed files. In CVS, the index is split over the <i>CVS/Entries</i> file and the arguments you pass to <code>cvs commit</code>. The CVS/Entires file keeps track of added and removed files while <code>cvs commit a b c</code> explicitly names the files, a b c, that have changed for the commit. When you work with git in day to day development you might not be aware of the index, but commands like <code>git add</code> and <code>git commit -a</code> work with it for you. Even <code>git diff</code> is actually giving you a diff of what is in the index and what is in your workspace. <code>git diff HEAD</code> gives you a diff since the last commit. Also, <code>git status</code> tells you about the state of the index, listing files that have changed and are included in the next commit along with files that are untracked and files that are changed but not included in the next commit. When performing a merge you want to be aware of what is in the merge's index.
+Often the merge will have no conflicts, but lets go over what you need to do when you end up with conflicts. First, some much needed background about how git works. When you have a branch checked out in your workspace git maintains what it calls an _index_. The index is essentially a record of what will go into the next commit you make. You can think of it as a record of what you have changed in a workspace, including added and removed files. In CVS, the index is split over the =CVS/Entries= file and the arguments you pass to =cvs commit=. The CVS/Entires file keeps track of added and removed files while =cvs commit a b c= explicitly names the files, a b c, that have changed for the commit. When you work with git in day to day development you might not be aware of the index, but commands like =git add= and =git commit -a= work with it for you. Even =git diff= is actually giving you a diff of what is in the index and what is in your workspace. =git diff HEAD= gives you a diff since the last commit. Also, =git status= tells you about the state of the index, listing files that have changed and are included in the next commit along with files that are untracked and files that are changed but not included in the next commit. When performing a merge you want to be aware of what is in the merge's index.
-<pre>
+{code}
$ git status
# On branch master
@@ -435,24 +429,24 @@
# (use "git add <file>..." to include in what will be committed)
#
# nmi_glue/test/post_all~HEAD
-</pre>
+{endcode}
-The output above has been slightly abbreviated. There are three sections and each is important to understand. The first is the status of the index. It lists all the changes the merge was able to make for you automatically. The second section contains a list of files where conflicts occurred. If you've done stable->development merges in the past you are likely familiar with some of these conflicts, namely <i>src/CVS_Tags</i>. The third section of the output is a list of files that the index knows nothing about. In this example it is just one file that the merge created for us.
+The output above has been slightly abbreviated. There are three sections and each is important to understand. The first is the status of the index. It lists all the changes the merge was able to make for you automatically. The second section contains a list of files where conflicts occurred. If you've done stable->development merges in the past you are likely familiar with some of these conflicts, namely =src/CVS_Tags=. The third section of the output is a list of files that the index knows nothing about. In this example it is just one file that the merge created for us.
-Now it is time to go through the <i>Changes to be committed:</i> list and make sure you want everything in it to happen. Keep in mind that the <i>modified:</i> files are those where the merge was successful, but you can still check to make sure they look good.
+Now it is time to go through the _Changes to be committed:_ list and make sure you want everything in it to happen. Keep in mind that the _modified:_ files are those where the merge was successful, but you can still check to make sure they look good.
-<pre>
+{code}
# If you don't want to delete nmi_tools/analysis/README, it is marked
# for deletion because it existed in master but not V7_0-branch
$ git checkout master nmi_tools/analysis/README
# If you want to delete a file that is marked as a "new file"
$ git rm src/condor_tests/cmd_wait_shows-notimeout.run
-</pre>
+{endcode}
-Next you should process the files with conflicts, those in the <i>Changed but not updated:</i> list.
+Next you should process the files with conflicts, those in the _Changed but not updated:_ list.
-<pre>
+{code}
# Edit src/CVS_Tags and resolve the conflict
$ emacs src/CVS_Tags
@@ -470,11 +464,11 @@
# into the commit
$ git add src/CVS_Tags
-</pre>
+{endcode}
-Once you resolve all conflicts you'll see the once conflicted files listed as <i>modified:</i> in the index, check with <code>git status</code>. At this point you are ready to commit your merge and push it to the central repository. After running it through NMI, of course.
+Once you resolve all conflicts you'll see the once conflicted files listed as _modified:_ in the index, check with =git status=. At this point you are ready to commit your merge and push it to the central repository. After running it through NMI, of course.
-<pre>
+{code}
# Commit merge
$ git commit -m "Merged 7.0 source into 7.1"
@@ -482,7 +476,7 @@
# Push the merge into the central repository for all to see
$ git push
-</pre>
+{endcode}
<h1> Checking out an older revision of Condor</h1>
