branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
+ If this option is not given, `git fetch` defaults to remote "origin".
branch.<name>.merge::
- When in branch <name>, it tells `git fetch` the default remote branch
- to be merged.
+ When in branch <name>, it tells `git fetch` the default refspec to
+ be marked for merging in FETCH_HEAD. The value has exactly to match
+ a remote part of one of the refspecs which are fetched from the remote
+ given by "branch.<name>.remote".
+ The merge information is used by `git pull` (which at first calls
+ `git fetch`) to lookup the default branch for merging. Without
+ this option, `git pull` defaults to merge the first refspec fetched.
+ Specify multiple values to get an octopus merge.
pager.color::
A boolean to enable/disable colored output when the pager is in
</td>\r
</tr></table>\r
</div>\r
-<p>You can update the shared repository with your changes by first commiting\r
-your changes, and then using:</p>\r
+<p>You can update the shared repository with your changes by first committing\r
+your changes, and then using the <a href="git-push.html">git-push(1)</a> command:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git push origin master</tt></pre>\r
possibly created from scratch or from a tarball (see the\r
<a href="tutorial.html">tutorial</a>), or imported from an already existing CVS\r
repository (see the next section).</p>\r
-<p>If your project's working directory is /home/alice/myproject, you can\r
-create a shared repository at /pub/repo.git with:</p>\r
+<p>Assume your existing repo is at /home/alice/myproject. Create a new "bare"\r
+repository (a repository without a working tree) and fetch your project into\r
+it:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git clone -bare /home/alice/myproject /pub/repo.git</tt></pre>\r
+<pre><tt>$ mkdir /pub/my-repo.git\r
+$ cd /pub/my-repo.git\r
+$ git --bare init-db --shared\r
+$ git --bare fetch /home/alice/myproject master:master</tt></pre>\r
</div></div>\r
<p>Next, give every team member read/write access to this repository. One\r
easy way to do this is to give all the team members ssh access to the\r
writable by that group:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ cd /pub\r
-$ chgrp -R $group repo.git\r
-$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s\r
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true</tt></pre>\r
+<pre><tt>$ chgrp -R $group /pub/my-repo.git</tt></pre>\r
</div></div>\r
<p>Make sure committers have a umask of at most 027, so that the directories\r
they create are writable and searchable by other group members.</p>\r
<div class="sectionbody">\r
<p>First, install version 2.1 or higher of cvsps from\r
<a href="http://www.cobite.com/cvsps/">http://www.cobite.com/cvsps/</a> and make\r
-sure it is in your path. The magic command line is then</p>\r
+sure it is in your path. Then cd to a checked out CVS working directory\r
+of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git cvsimport -v -d <cvsroot> -C <destination> <module></tt></pre>\r
+<pre><tt>$ git cvsimport -C <destination></tt></pre>\r
</div></div>\r
<p>This puts a git archive of the named CVS module in the directory\r
-<destination>, which will be created if necessary. The -v option makes\r
-the conversion script very chatty.</p>\r
+<destination>, which will be created if necessary.</p>\r
<p>The import checks out from CVS every revision of every file. Reportedly\r
cvsimport can average some twenty revisions per second, so for a\r
medium-sized project this should not take more than a couple of minutes.\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 08-Dec-2006 07:23:38 UTC\r
+Last updated 09-Dec-2006 21:15:38 UTC\r
</div>\r
</div>\r
</body>\r
------------
================================
-You can update the shared repository with your changes by first commiting
-your changes, and then using:
+You can update the shared repository with your changes by first committing
+your changes, and then using the gitlink:git-push[1] command:
------------------------------------------------
$ git push origin master
link:tutorial.html[tutorial]), or imported from an already existing CVS
repository (see the next section).
-If your project's working directory is /home/alice/myproject, you can
-create a shared repository at /pub/repo.git with:
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
------------------------------------------------
-$ git clone -bare /home/alice/myproject /pub/repo.git
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init-db --shared
+$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
Next, give every team member read/write access to this repository. One
writable by that group:
------------------------------------------------
-$ cd /pub
-$ chgrp -R $group repo.git
-$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+$ chgrp -R $group /pub/my-repo.git
------------------------------------------------
Make sure committers have a umask of at most 027, so that the directories
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
-sure it is in your path. The magic command line is then
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run gitlink:git-cvsimport[1]:
-------------------------------------------
-$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+$ git cvsimport -C <destination>
-------------------------------------------
This puts a git archive of the named CVS module in the directory
-<destination>, which will be created if necessary. The -v option makes
-the conversion script very chatty.
+<destination>, which will be created if necessary.
The import checks out from CVS every revision of every file. Reportedly
cvsimport can average some twenty revisions per second, so for a
<dd>\r
<p>\r
When in branch <name>, it tells <tt>git fetch</tt> which remote to fetch.\r
+ If this option is not given, <tt>git fetch</tt> defaults to remote "origin".\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- When in branch <name>, it tells <tt>git fetch</tt> the default remote branch\r
- to be merged.\r
+ When in branch <name>, it tells <tt>git fetch</tt> the default refspec to\r
+ be marked for merging in FETCH_HEAD. The value has exactly to match\r
+ a remote part of one of the refspecs which are fetched from the remote\r
+ given by "branch.<name>.remote".\r
+ The merge information is used by <tt>git pull</tt> (which at first calls\r
+ <tt>git fetch</tt>) to lookup the default branch for merging. Without\r
+ this option, <tt>git pull</tt> defaults to merge the first refspec fetched.\r
+ Specify multiple values to get an octopus merge.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Nov-2006 20:39:59 UTC\r
+Last updated 09-Dec-2006 21:15:37 UTC\r
</div>\r
</div>\r
</body>\r
projects / git.git / commitdiff