$ git config --global core.editor "/usr/ucb/vi"
{endcode}
-This edits the per-user git config file that is global across all repos. git config edits the =~/.gitconfig file=, which is a .ini style file.
+This edits the per-user git config file that is global across all repos. git config edits the =~/.gitconfig file=, which is an =.ini= style file.
On Windows you may also want to run:
@@ -46,42 +46,42 @@
Alternatively, if you do want to use =core.autocrlf=, then you should also enable =core.safecrlf=:
-<pre>
+{code}
git config --global core.autocrlf true
git config --global core.safecrlf true
-</pre>
+{endcode}
-The <code>core.safecrlf</code> option forces git to ensure that converting CRLF to LF and vice versa will not corrupt the data. This does not concern most text files, but it may save you from killing a perfectly good binary file.
+The =core.safecrlf= option forces git to ensure that converting CRLF to LF and vice versa will not corrupt the data. This does not concern most text files, but it may save you from killing a perfectly good binary file.
-<h3>Cloning the main Condor source repository</h3>
+{subsection: Cloning the main Condor source repository}
The first thing you need to do is to clone the main git source repo. This gives you a whole copy of all the condor source code and its history on your machine. As of February 2, 2009, CONDOR_SRC.git is about 339 MB in size.
-<pre>
+{code}
$ cd /p/condor/workspaces/your_login
$ git clone /p/condor/repository/CONDOR_SRC.git
-</pre>
+{endcode}
-Note that /p/condor/workspaces/your_login/CONDOR_SRC/src contains the latest checked out Condor source. The metadata for the whole tree is stored in /p/condor/workspaces/your_login/CONDOR_SRC/.git. The files under /p/condor/workspaces/your_login/CONDOR_SRC, known as your workspace, will change as you switch from branch to branch.
+Note that =/p/condor/workspaces/your_login/CONDOR_SRC/src= contains the latest checked out Condor source. The metadata for the whole tree is stored in =/p/condor/workspaces/your_login/CONDOR_SRC/.git=. The files under =/p/condor/workspaces/your_login/CONDOR_SRC=, known as your workspace, will change as you switch from branch to branch.
-<h3>Cloning the main Condor manual repository</h3>
+{subsection: Cloning the main Condor manual repository}
You clone the Condor manual repository in the same way you cloned the source repository, only the central repository location is different.
-<pre>
+{code}
$ cd /p/condor/workspaces/your_login
$ git clone /p/condor/repository/CONDOR_DOC.git
-</pre>
+{endcode}
-This will create /p/condor/workspaces/your_login/CONDOR_DOC. The source and manual are stored in separate repositories to make branching and merging them independently possible. Whenever you want to merge or branch the manual you should coordinate with Karen.
+This will create =/p/condor/workspaces/your_login/CONDOR_DOC=. The source and manual are stored in separate repositories to make branching and merging them independently possible. Whenever you want to merge or branch the manual you should coordinate with Karen.
-If you don't like the name CONDOR_DOC you can feel free to rename the directory to anything you want.
+If you don't like the name =CONDOR_DOC= you can feel free to rename the directory to anything you want.
-<h3>Create names for the stable and development branches in your local repo</h3>
+{subsection: Create names for the stable and development branches in your local repo}
Git differentiates between branches in your local repo and those in remote repos, for us that is the central Condor repo. In addition to creating entirely local branches, git lets you create local branches that track remote branches. Tracking means when something changes on the remote branch you can have those changes reflected in your repository. Having a local branch that tracks a remote branch is also the best way to commit changes to a remote branch. In general, Condor developers should always keep local branches that track the stable and development branches in the central Condor repository. Assuming the stable series is 7.0, and the development is 7.1, issue the following commands:
-<pre>
+{code}
$ cd /p/condor/workspaces/your_login/CONDOR_SRC
# Create a local V7_0-branch to track the central V7_0-branch
@@ -94,11 +94,11 @@
# And if you have a clone of the manual too
$ cd /p/condor/workspaces/your_login/CONDOR_DOC
$ git branch V7_0-branch origin/V7_0-branch
-</pre>
+{endcode}
-The CONDOR_EXT.git repository is handled a bit differently. It does not treat its primary, "master", branch as the development series by default. Instead you will need to create a <code>V7_1-branch</code> from the central repository's <code>V7_1-branch</code>. Like so:
+The =CONDOR_EXT.git= repository is handled a bit differently. It does not treat its primary, "master", branch as the development series by default. Instead you will need to create a =V7_1-branch= from the central repository's =V7_1-branch=. Like so:
-<pre>
+{code}
$ cd /p/condor/workspaces/your_login
$ git clone /p/condor/repository/CONDOR_EXT.git
@@ -106,37 +106,37 @@
$ git branch V7_0-branch origin/V7_0-branch
$ git branch V7_1-branch origin/V7_1-branch
-</pre>
+{endcode}
-And that's all you need! You are now good to go. It wouldn't hurt to clean up any unreachable objects nows, it doesn't take long, and it makes the repo smaller and faster. You can run this in both your CONDOR_SRC.git repository or your CONDOR_DOC.git repository:
+And that's all you need! You are now good to go. It wouldn't hurt to clean up any unreachable objects nows, it doesn't take long, and it makes the repo smaller and faster. You can run this in both your =CONDOR_SRC.git= repository or your =CONDOR_DOC.git= repository:
-<pre>
+{code}
$ git gc --prune
-</pre>
+{endcode}
-<h2>Getting the latest upstream code</h2>
+{section: Getting the latest upstream code}
There are two ways to update your local repository. Which one to use depends on whether you have committed changes in the meantime.
-<h4>No changes: pull</h4>
+{subsubsection: No changes: pull}
The command to update your local repository is:
-<pre>
+{code}
git pull
-</pre>
+{endcode}
It will pull down the latest repository information from the origin remote file (which points at where you initially cloned the repository from), then merge. If the new changes don't conflict with anything locally, the merge will "fast-forward" your branch reference to the new head. If new changes do conflict, it will try to do an automatic merge using a couple of different schemes, and then automatically commits the merge if it's satisfied. If you notice that your pull resulted in a merge (in the output of pull), you might want to use gitk to see if the merge did what you expected it to. If it isn't satisfied, then you have to resolve the conflict manually.
-<h4>You've made changes: fetch and rebase</h4>
+{subsubsection: You've made changes: fetch and rebase}
If you have committed local changes, then git-pull will create a spurious "Merge" commit, which will pollute the change list when you later push upstream. To avoid this, do these two commands:
-<pre>
+{code}
git fetch
git rebase origin/some_branch
-</pre>
+{endcode}
-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 <code>git rebase origin/V7_0-branch</code>.
+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>
