@@ -52,7 +52,9 @@ your new project. You will now have a `.git` directory, and you can
5252inspect that with `ls`. For your new empty project, it should show you
5353three entries, among other things:
5454
55- - a symlink called `HEAD`, pointing to `refs/heads/master`
55+ - a symlink called `HEAD`, pointing to `refs/heads/master` (if your
56+ platform does not have native symlinks, it is a file containing the
57+ line "ref: refs/heads/master")
5658+
5759Don't worry about the fact that the file that the `HEAD` link points to
5860doesn't even exist yet -- you haven't created the commit that will
@@ -228,6 +230,7 @@ which will spit out
228230
229231------------
230232diff --git a/hello b/hello
233+ index 557db03..263414f 100644
231234--- a/hello
232235+++ b/hello
233236@@ -1 +1,2 @@
@@ -290,13 +293,14 @@ also wants to get a commit message
290293on its standard input, and it will write out the resulting object name for the
291294commit to its standard output.
292295
293- And this is where we start using the `.git/HEAD ` file. The `HEAD` file is
296+ And this is where we create the `.git/refs/heads/master ` file. This file is
294297supposed to contain the reference to the top-of-tree, and since that's
295298exactly what `git-commit-tree` spits out, we can do this all with a simple
296299shell pipeline:
297300
298301------------------------------------------------
299- echo "Initial commit" | git-commit-tree $(git-write-tree) > .git/HEAD
302+ echo "Initial commit" | \
303+ git-commit-tree $(git-write-tree) > .git/refs/heads/master
300304------------------------------------------------
301305
302306which will say:
@@ -692,33 +696,49 @@ other point in the history than the current `HEAD`, you can do so by
692696just telling `git checkout` what the base of the checkout would be.
693697In other words, if you have an earlier tag or branch, you'd just do
694698
695- git checkout -b mybranch earlier-commit
699+ ------------
700+ git checkout -b mybranch earlier-commit
701+ ------------
696702
697703and it would create the new branch `mybranch` at the earlier commit,
698704and check out the state at that time.
699705================================================
700706
701707You can always just jump back to your original `master` branch by doing
702708
703- git checkout master
709+ ------------
710+ git checkout master
711+ ------------
704712
705713(or any other branch-name, for that matter) and if you forget which
706714branch you happen to be on, a simple
707715
708- ls -l .git/HEAD
716+ ------------
717+ ls -l .git/HEAD
718+ ------------
709719
710- will tell you where it's pointing. To get the list of branches
711- you have , you can say
720+ will tell you where it's pointing (Note that on platforms with bad or no
721+ symlink support , you have to execute
712722
713- git branch
723+ ------------
724+ cat .git/HEAD
725+ ------------
726+
727+ instead). To get the list of branches you have, you can say
728+
729+ ------------
730+ git branch
731+ ------------
714732
715733which is nothing more than a simple script around `ls .git/refs/heads`.
716734There will be asterisk in front of the branch you are currently on.
717735
718736Sometimes you may wish to create a new branch _without_ actually
719737checking it out and switching to it. If so, just use the command
720738
721- git branch <branchname> [startingpoint]
739+ ------------
740+ git branch <branchname> [startingpoint]
741+ ------------
722742
723743which will simply _create_ the branch, but will not do anything further.
724744You can then later -- once you decide that you want to actually develop
@@ -844,7 +864,6 @@ $ git show-branch master mybranch
844864 ! [mybranch] Some work.
845865--
846866+ [master] Merged "mybranch" changes.
847- + [master~1] Some fun.
848867++ [mybranch] Some work.
849868------------------------------------------------
850869
@@ -871,8 +890,10 @@ Now, let's pretend you are the one who did all the work in
871890to the `master` branch. Let's go back to `mybranch`, and run
872891resolve to get the "upstream changes" back to your branch.
873892
874- git checkout mybranch
875- git resolve HEAD master "Merge upstream changes."
893+ ------------
894+ git checkout mybranch
895+ git resolve HEAD master "Merge upstream changes."
896+ ------------
876897
877898This outputs something like this (the actual commit object names
878899would be different)
@@ -1088,13 +1109,17 @@ i.e. `<project>.git`. Let's create such a public repository for
10881109project `my-git`. After logging into the remote machine, create
10891110an empty directory:
10901111
1091- mkdir my-git.git
1112+ ------------
1113+ mkdir my-git.git
1114+ ------------
10921115
10931116Then, make that directory into a GIT repository by running
10941117`git init-db`, but this time, since its name is not the usual
10951118`.git`, we do things slightly differently:
10961119
1097- GIT_DIR=my-git.git git-init-db
1120+ ------------
1121+ GIT_DIR=my-git.git git-init-db
1122+ ------------
10981123
10991124Make sure this directory is available for others you want your
11001125changes to be pulled by via the transport of your choice. Also
@@ -1118,7 +1143,9 @@ Your "public repository" is now ready to accept your changes.
11181143Come back to the machine you have your private repository. From
11191144there, run this command:
11201145
1121- git push <public-host>:/path/to/my-git.git master
1146+ ------------
1147+ git push <public-host>:/path/to/my-git.git master
1148+ ------------
11221149
11231150This synchronizes your public repository to match the named
11241151branch head (i.e. `master` in this case) and objects reachable
@@ -1128,7 +1155,9 @@ As a real example, this is how I update my public git
11281155repository. Kernel.org mirror network takes care of the
11291156propagation to other publicly visible machines:
11301157
1131- git push master.kernel.org:/pub/scm/git/git.git/
1158+ ------------
1159+ git push master.kernel.org:/pub/scm/git/git.git/
1160+ ------------
11321161
11331162
11341163Packing your repository
@@ -1141,7 +1170,9 @@ not so convenient to transport over the network. Since git objects are
11411170immutable once they are created, there is a way to optimize the
11421171storage by "packing them together". The command
11431172
1144- git repack
1173+ ------------
1174+ git repack
1175+ ------------
11451176
11461177will do it for you. If you followed the tutorial examples, you
11471178would have accumulated about 17 objects in `.git/objects/??/`
@@ -1165,7 +1196,9 @@ Our programs are always perfect ;-).
11651196Once you have packed objects, you do not need to leave the
11661197unpacked objects that are contained in the pack file anymore.
11671198
1168- git prune-packed
1199+ ------------
1200+ git prune-packed
1201+ ------------
11691202
11701203would remove them for you.
11711204
0 commit comments