<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
<style type="text/css">\r
/* Debug borders */\r
p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
<ul>\r
<li>\r
<p>\r
-a symlink called <tt>HEAD</tt>, pointing to <tt>refs/heads/master</tt> (if your\r
- platform does not have native symlinks, it is a file containing the\r
- line "ref: refs/heads/master")\r
+a file called <tt>HEAD</tt>, that has <tt>ref: refs/heads/master</tt> in it.\r
+ This is similar to a symbolic link and points at\r
+ <tt>refs/heads/master</tt> relative to the <tt>HEAD</tt> file.\r
</p>\r
<p>Don't worry about the fact that the file that the <tt>HEAD</tt> link points to\r
doesn't even exist yet — you haven't created the commit that will\r
<em>tags</em> that you have created to name specific versions in your\r
repository.</p>\r
<p>One note: the special <tt>master</tt> head is the default branch, which is\r
-why the <tt>.git/HEAD</tt> file was created as a symlink to it even if it\r
+why the <tt>.git/HEAD</tt> file was created points to it even if it\r
doesn't yet exist. Basically, the <tt>HEAD</tt> link is supposed to always\r
point to the branch you are working on right now, and you always\r
start out expecting to work on the <tt>master</tt> branch.</p>\r
<pre><tt>$ echo "Hello World" >hello\r
$ echo "Silly example" >example</tt></pre>\r
</div></div>\r
-<p>you have now created two files in your working tree (aka <em>working directory</em>), but to\r
-actually check in your hard work, you will have to go through two steps:</p>\r
+<p>you have now created two files in your working tree (aka <em>working directory</em>),\r
+but to actually check in your hard work, you will have to go through two steps:</p>\r
<ul>\r
<li>\r
<p>\r
<pre><tt>.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238\r
.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962</tt></pre>\r
</div></div>\r
-<p>which correspond with the objects with names of 557db… and f24c7..\r
-respectively.</p>\r
+<p>which correspond with the objects with names of <tt>557db…</tt> and\r
+<tt>f24c7…</tt> respectively.</p>\r
<p>If you want to, you can use <tt>git-cat-file</tt> to look at those objects, but\r
you'll have to use the object name, not the filename of the object:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git-cat-file "blob" 557db03</tt></pre>\r
</div></div>\r
-<p>which will print out "Hello World". The object 557db03 is nothing\r
+<p>which will print out "Hello World". The object <tt>557db03</tt> is nothing\r
more than the contents of your file <tt>hello</tt>.</p>\r
<div class="admonitionblock">\r
<table><tr>\r
</td>\r
</tr></table>\r
</div>\r
-<p>More interestingly, you can also give <tt>git-diff-tree</tt> the <tt>-v</tt> flag, which\r
-tells it to also show the commit message and author and date of the\r
+<p>More interestingly, you can also give <tt>git-diff-tree</tt> the <tt>—pretty</tt> flag,\r
+which tells it to also show the commit message and author and date of the\r
commit, and you can tell it to show a whole series of diffs.\r
Alternatively, you can tell it to be "silent", and not show the diffs at\r
all, but just show the actual commit message.</p>\r
branch you happen to be on, a simple</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ ls -l .git/HEAD</tt></pre>\r
-</div></div>\r
-<p>will tell you where it's pointing (Note that on platforms with bad or no\r
-symlink support, you have to execute</p>\r
-<div class="listingblock">\r
-<div class="content">\r
<pre><tt>$ cat .git/HEAD</tt></pre>\r
</div></div>\r
-<p>instead). To get the list of branches you have, you can say</p>\r
+<p>will tell you where it's pointing. To get the list of branches\r
+you have, you can say</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git branch</tt></pre>\r
<div class="content">\r
<pre><tt>$ git checkout mybranch\r
$ echo "Work, work, work" >>hello\r
-$ git commit -m 'Some work.' hello</tt></pre>\r
+$ git commit -m 'Some work.' -i hello</tt></pre>\r
</div></div>\r
<p>Here, we just added another line to <tt>hello</tt>, and we used a shorthand for\r
doing both <tt>git-update-index hello</tt> and <tt>git commit</tt> by just giving the\r
-filename directly to <tt>git commit</tt>. The <tt>-m</tt> flag is to give the\r
+filename directly to <tt>git commit</tt>, with an <tt>-i</tt> flag (it tells\r
+git to <em>include</em> that file in addition to what you have done to\r
+the index file so far when making the commit). The <tt>-m</tt> flag is to give the\r
commit log message from the command line.</p>\r
<p>Now, to make it a bit more interesting, let's assume that somebody else\r
does some work in the original branch, and simulate that by going back\r
<div class="content">\r
<pre><tt>$ echo "Play, play, play" >>hello\r
$ echo "Lots of fun" >>example\r
-$ git commit -m 'Some fun.' hello example</tt></pre>\r
+$ git commit -m 'Some fun.' -i hello example</tt></pre>\r
</div></div>\r
<p>since the master branch is obviously in a much better mood.</p>\r
<p>Now, you've got two branches, and you decide that you want to merge the\r
...\r
Auto-merging hello\r
CONFLICT (content): Merge conflict in hello\r
- Automatic merge failed/prevented; fix up by hand</tt></pre>\r
+ Automatic merge failed; fix up by hand</tt></pre>\r
</div></div>\r
<p>which is way too verbose, but it basically tells you that it failed the\r
really trivial merge ("Simple merge") and did an "Automatic merge"\r
<p>and once you're happy with your manual merge, just do a</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git commit hello</tt></pre>\r
+<pre><tt>$ git commit -i hello</tt></pre>\r
</div></div>\r
<p>which will very loudly warn you that you're now committing a merge\r
(which is correct, so never mind), and you can write a small merge\r
environment, is <tt>git show-branch</tt>.</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git show-branch master mybranch\r
+<pre><tt>$ git show-branch --topo-order master mybranch\r
* [master] Merge work in mybranch\r
! [mybranch] Some work.\r
--\r
<p>The first two lines indicate that it is showing the two branches\r
and the first line of the commit log message from their\r
top-of-the-tree commits, you are currently on <tt>master</tt> branch\r
-(notice the asterisk <tt><strong></tt> character), and the first column for\r
+(notice the asterisk <tt>*</tt> character), and the first column for\r
the later output lines is used to show commits contained in the\r
<tt>master</tt> branch, and the second column for the <tt>mybranch</tt>\r
branch. Three commits are shown along with their log messages.\r
-All of them have non blank characters in the first column (<tt></strong></tt>\r
+All of them have non blank characters in the first column (<tt>*</tt>\r
shows an ordinary commit on the current branch, <tt>.</tt> is a merge commit), which\r
means they are now part of the <tt>master</tt> branch. Only the "Some\r
work" commit has the plus <tt>+</tt> character in the second column,\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>Updating from ae3a2da... to a80b4aa....\r
+Fast forward\r
example | 1 +\r
hello | 1 +\r
2 files changed, 2 insertions(+), 0 deletions(-)</tt></pre>\r
suggested in the previous section may be new to you. You do not\r
have to worry. git supports "shared public repository" style of\r
cooperation you are probably more familiar with as well.</p>\r
-<p>For this, set up a public repository on a machine that is\r
-reachable via SSH by people with "commit privileges". Put the\r
-committers in the same user group and make the repository\r
-writable by that group. Make sure their umasks are set up to\r
-allow group members to write into directories other members\r
-have created.</p>\r
-<p>You, as an individual committer, then:</p>\r
-<ul>\r
-<li>\r
-<p>\r
-First clone the shared repository to a local repository:\r
-</p>\r
-</li>\r
-</ul>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git clone repo.shared.xz:/pub/scm/project.git/ my-project\r
-$ cd my-project\r
-$ hack away</tt></pre>\r
-</div></div>\r
-<ul>\r
-<li>\r
-<p>\r
-Merge the work others might have done while you were hacking\r
- away:\r
-</p>\r
-</li>\r
-</ul>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git pull origin\r
-$ test the merge result</tt></pre>\r
-</div></div>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">\r
-<p>The first <tt>git clone</tt> would have placed the following in\r
-<tt>my-project/.git/remotes/origin</tt> file, and that's why this and\r
-the next step work.</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>URL: repo.shared.xz:/pub/scm/project.git/ my-project\r
-Pull: master:origin</tt></pre>\r
-</div></div>\r
-</td>\r
-</tr></table>\r
-</div>\r
-<ul>\r
-<li>\r
-<p>\r
-push your work as the new head of the shared\r
- repository.\r
-</p>\r
-</li>\r
-</ul>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git push origin master</tt></pre>\r
-</div></div>\r
-<p>If somebody else pushed into the same shared repository while\r
-you were working locally, <tt>git push</tt> in the last step would\r
-complain, telling you that the remote <tt>master</tt> head does not\r
-fast forward. You need to pull and merge those other changes\r
-back before you push your work when it happens.</p>\r
-<p>The <tt>git push</tt> command without any explicit refspec parameter\r
-pushes the refs that exist both in the local repository and the\r
-remote repository. So the last <tt>push</tt> can be done with either\r
-one of these:</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git push origin\r
-$ git push repo.shared.xz:/pub/scm/project.git/</tt></pre>\r
-</div></div>\r
-<p>as long as the shared repository does not have any branches\r
-other than <tt>master</tt>.\r
-[NOTE]</p>\r
-<div class="exampleblock">\r
-<div class="exampleblock-content">\r
-<p>If you created your shared repository by cloning from somewhere\r
-else, you may have the <tt>origin</tt> branch. Your developers\r
-typically do not use that branch; remove it. Otherwise, that\r
-would be pushed back by the <tt>git push origin</tt> because your\r
-developers' repository would surely have <tt>origin</tt> branch to keep\r
-track of the shared repository, and would be counted as "exist\r
-on both ends".</p>\r
-</div></div>\r
-</div>\r
-<h2>Advanced Shared Repository Management</h2>\r
-<div class="sectionbody">\r
-<p>Being able to push into a shared repository means being able to\r
-write into it. If your developers are coming over the network,\r
-this means you, as the repository administrator, need to give\r
-each of them an SSH access to the shared repository machine.</p>\r
-<p>In some cases, though, you may not want to give a normal shell\r
-account to them, but want to restrict them to be able to only\r
-do <tt>git push</tt> into the repository and nothing else.</p>\r
-<p>You can achieve this by setting the login shell of your\r
-developers on the shared repository host to <tt>git-shell</tt> program.</p>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">Most likely you would also need to list <tt>git-shell</tt> program in\r
-<tt>/etc/shells</tt> file.</td>\r
-</tr></table>\r
-</div>\r
-<p>This restricts the set of commands that can be run from incoming\r
-SSH connection for these users to only <tt>receive-pack</tt> and\r
-<tt>upload-pack</tt>, so the only thing they can do are <tt>git fetch</tt> and\r
-<tt>git push</tt>.</p>\r
-<p>You still need to create UNIX user accounts for each developer,\r
-and put them in the same group. Make sure that the repository\r
-shared among these developers is writable by that group.</p>\r
-<ol>\r
-<li>\r
-<p>\r
-Initializing the shared repository with <tt>git-init-db —shared</tt>\r
-helps somewhat.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Run the following in the shared repository:\r
-</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ chgrp -R $group repo.git\r
-$ find repo.git -type d -print | xargs chmod ug+rwx,g+s\r
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true</tt></pre>\r
-</div></div>\r
-</li>\r
-</ol>\r
-<p>The above measures make sure that directories lazily created in\r
-<tt>$GIT_DIR</tt> are writable by group members. You, as the\r
-repository administrator, are still responsible to make sure\r
-your developers belong to that shared repository group and set\r
-their umask to a value no stricter than 027 (i.e. at least allow\r
-reading and searching by group members).</p>\r
-<p>You can implement finer grained branch policies using update\r
-hooks. There is a document ("control access to branches") in\r
-Documentation/howto by Carl Baldwin and JC outlining how to (1)\r
-limit access to branch per user, (2) forbid overwriting existing\r
-tags.</p>\r
+<p>See <a href="cvs-migration.txt">git for CVS users</a> for the details.</p>\r
</div>\r
<h2>Bundling your work together</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 22-Jan-2006 23:54:24 PDT\r
+Last updated 07-May-2006 23:36:13 UTC\r
</div>\r
</div>\r
</body>\r
projects / git.git / blobdiff