![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 2bbe7dea377d2df0b9dbcf59228a599401aae972..e4dd5518c81ac98ef3da9cbb1cea4a9e1fe6e62c 100644 (file)
which is just git's way of saying that you haven't been doing anything
strange, and that it will have created a local `.git` directory setup for
your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
+inspect that with 'ls'. For your new empty project, it should show you
three entries, among other things:
- a file called `HEAD`, that has `ref: refs/heads/master` in it.
------------
Oops. That wasn't very readable. It just spit out its own internal
-version of a `diff`, but that internal version really just tells you
+version of a 'diff', but that internal version really just tells you
that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
While creating changes is useful, it's even more useful if you can tell
later what changed. The most useful command for this is another of the
-`diff` family, namely 'git-diff-tree'.
+'diff' family, namely 'git-diff-tree'.
'git-diff-tree' can be given two arbitrary trees, and it will tell you the
differences between them. Perhaps even more commonly, though, you can
Note that the second point is true even across machines. You can
duplicate a remote git repository with *any* regular copy mechanism, be it
-`scp`, `rsync` or `wget`.
+'scp', 'rsync' or 'wget'.
When copying a remote repository, you'll want to at a minimum update the
index cache when you do this, and especially with other peoples'
histories. You can also see exactly how they came to be from a common
source.
-Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
+Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want
to merge the work we did on the `mybranch` branch into the `master`
branch (which is currently our `HEAD` too). To do that, there's a nice
script called 'git-merge', which wants to know which branches you want
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
- Automatic merge failed; fix up by hand
+ Automatic merge failed; fix conflicts and then commit the result.
----------------
It tells you that it did an "Automatic merge", which
----------------
Updating from ae3a2da... to a80b4aa....
-Fast forward
+Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
----------------
-Because your branch did not contain anything more than what are
-already merged into the `master` branch, the merge operation did
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
You can run `gitk \--all` again to see how the commit ancestry
-looks like, or run `show-branch`, which tells you this.
+looks like, or run 'show-branch', which tells you this.
------------------------------------------------
$ git show-branch master mybranch
Local directory::
`/path/to/repo.git/`
+
-This transport is the same as SSH transport but uses `sh` to run
+This transport is the same as SSH transport but uses 'sh' to run
both ends on the local machine instead of running other end on
-the remote machine via `ssh`.
+the remote machine via 'ssh'.
git Native::
`git://remote.machine/path/to/repo.git/`
------------
$ git merge-index git-merge-one-file hello
-Auto-merging hello.
-merge: warning: conflicts during merge
-ERROR: Merge conflict in hello.
+Auto-merging hello
+ERROR: Merge conflict in hello
fatal: merge program failed
------------
describe those three versions, and is responsible to leave the
merge results in the working tree.
It is a fairly straightforward shell script, and
-eventually calls `merge` program from RCS suite to perform a
-file-level 3-way merge. In this case, `merge` detects
+eventually calls 'merge' program from RCS suite to perform a
+file-level 3-way merge. In this case, 'merge' detects
conflicts, and the merge result with conflict marks is left in
the working tree.. This can be seen if you run `ls-files
--stage` again at this point:
------------
Make sure this directory is available for others you want your
-changes to be pulled by via the transport of your choice. Also
+changes to be pulled via the transport of your choice. Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
[NOTE]
Many installations of sshd do not invoke your shell as the login
shell when you directly run programs; what this means is that if
-your login shell is `bash`, only `.bashrc` is read and not
+your login shell is 'bash', only `.bashrc` is read and not
`.bash_profile`. As a workaround, make sure `.bashrc` sets up
`$PATH` so that you can run 'git-receive-pack' program.
[NOTE]
If you plan to publish this repository to be accessed over http,
-you should do `chmod +x my-git.git/hooks/post-update` at this
-point. This makes sure that every time you push into this
+you should do `mv my-git.git/hooks/post-update.sample
+my-git.git/hooks/post-update` at this point.
+This makes sure that every time you push into this
repository, `git update-server-info` is run.
Your "public repository" is now ready to accept your changes.
never.
If you run `git repack` again at this point, it will say
-"Nothing to pack". Once you continue your development and
+"Nothing new to pack.". Once you continue your development and
accumulate the changes, running `git repack` again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
If other people are pulling from your repository over dumb
transport protocols (HTTP), you need to keep this repository
'dumb transport friendly'. After `git init`,
-`$GIT_DIR/hooks/post-update` copied from the standard templates
-would contain a call to 'git-update-server-info' but the
-`post-update` hook itself is disabled by default -- enable it
-with `chmod +x post-update`. This makes sure 'git-update-server-info'
-keeps the necessary files up-to-date.
+`$GIT_DIR/hooks/post-update.sample` copied from the standard templates
+would contain a call to 'git-update-server-info'
+but you need to manually enable the hook with
+`mv post-update.sample post-update`. This makes sure
+'git-update-server-info' keeps the necessary files up-to-date.
3. Push into the public repository from your primary
repository.
6. Push your changes to the public repository, and announce it
to the public.
-7. Every once in a while, "git-repack" the public repository.
+7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
$ git reset --hard master~2
------------
-You can make sure 'git show-branch' matches the state before
+You can make sure `git show-branch` matches the state before
those two 'git-merge' you just did. Then, instead of running
two 'git-merge' commands in a row, you would merge these two
branch heads (this is known as 'making an Octopus'):
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
+link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT