![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 00f4bab954f9d40000593bdfa04145ca5504b680..36f42e051c610a89c5bbebb56c52817815c81adf 100644 (file)
inspect that with `ls`. For your new empty project, it should show you
three entries, among other things:
inspect that with `ls`. For your new empty project, it should show you
three entries, among other things:
- - a symlink called `HEAD`, pointing to `refs/heads/master` (if your
- platform does not have native symlinks, it is a file containing the
- line "ref: refs/heads/master")
+ - a symlink called `HEAD`, pointing to `refs/heads/master`
+
Don't worry about the fact that the file that the `HEAD` link points to
doesn't even exist yet -- you haven't created the commit that will
+
Don't worry about the fact that the file that the `HEAD` link points to
doesn't even exist yet -- you haven't created the commit that will
------------
diff --git a/hello b/hello
------------
diff --git a/hello b/hello
-index 557db03..263414f 100644
--- a/hello
+++ b/hello
@@ -1 +1,2 @@
--- a/hello
+++ b/hello
@@ -1 +1,2 @@
on its standard input, and it will write out the resulting object name for the
commit to its standard output.
on its standard input, and it will write out the resulting object name for the
commit to its standard output.
-And this is where we create the `.git/refs/heads/master` file. This file is
+And this is where we start using the `.git/HEAD` file. The `HEAD` file is
supposed to contain the reference to the top-of-tree, and since that's
exactly what `git-commit-tree` spits out, we can do this all with a simple
shell pipeline:
------------------------------------------------
supposed to contain the reference to the top-of-tree, and since that's
exactly what `git-commit-tree` spits out, we can do this all with a simple
shell pipeline:
------------------------------------------------
-echo "Initial commit" | \
- git-commit-tree $(git-write-tree) > .git/refs/heads/master
+echo "Initial commit" | git-commit-tree $(git-write-tree) > .git/HEAD
------------------------------------------------
which will say:
------------------------------------------------
which will say:
just telling `git checkout` what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
just telling `git checkout` what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
-------------
-git checkout -b mybranch earlier-commit
-------------
+ git checkout -b mybranch earlier-commit
and it would create the new branch `mybranch` at the earlier commit,
and check out the state at that time.
and it would create the new branch `mybranch` at the earlier commit,
and check out the state at that time.
You can always just jump back to your original `master` branch by doing
You can always just jump back to your original `master` branch by doing
-------------
-git checkout master
-------------
+ git checkout master
(or any other branch-name, for that matter) and if you forget which
branch you happen to be on, a simple
(or any other branch-name, for that matter) and if you forget which
branch you happen to be on, a simple
-------------
-ls -l .git/HEAD
-------------
+ ls -l .git/HEAD
-will tell you where it's pointing (Note that on platforms with bad or no
-symlink support, you have to execute
+will tell you where it's pointing. To get the list of branches
+you have, you can say
-------------
-cat .git/HEAD
-------------
-
-instead). To get the list of branches you have, you can say
-
-------------
-git branch
-------------
+ git branch
which is nothing more than a simple script around `ls .git/refs/heads`.
There will be asterisk in front of the branch you are currently on.
which is nothing more than a simple script around `ls .git/refs/heads`.
There will be asterisk in front of the branch you are currently on.
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
-------------
-git branch <branchname> [startingpoint]
-------------
+ git branch <branchname> [startingpoint]
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
! [mybranch] Some work.
--
+ [master] Merged "mybranch" changes.
! [mybranch] Some work.
--
+ [master] Merged "mybranch" changes.
++ [master~1] Some fun.
++ [mybranch] Some work.
------------------------------------------------
++ [mybranch] Some work.
------------------------------------------------
to the `master` branch. Let's go back to `mybranch`, and run
resolve to get the "upstream changes" back to your branch.
to the `master` branch. Let's go back to `mybranch`, and run
resolve to get the "upstream changes" back to your branch.
-------------
-git checkout mybranch
-git resolve HEAD master "Merge upstream changes."
-------------
+ git checkout mybranch
+ git resolve HEAD master "Merge upstream changes."
This outputs something like this (the actual commit object names
would be different)
This outputs something like this (the actual commit object names
would be different)
project `my-git`. After logging into the remote machine, create
an empty directory:
project `my-git`. After logging into the remote machine, create
an empty directory:
-------------
-mkdir my-git.git
-------------
+ mkdir my-git.git
Then, make that directory into a GIT repository by running
`git init-db`, but this time, since its name is not the usual
`.git`, we do things slightly differently:
Then, make that directory into a GIT repository by running
`git init-db`, but this time, since its name is not the usual
`.git`, we do things slightly differently:
-------------
-GIT_DIR=my-git.git git-init-db
-------------
+ GIT_DIR=my-git.git git-init-db
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
Come back to the machine you have your private repository. From
there, run this command:
Come back to the machine you have your private repository. From
there, run this command:
-------------
-git push <public-host>:/path/to/my-git.git master
-------------
+ git push <public-host>:/path/to/my-git.git master
This synchronizes your public repository to match the named
branch head (i.e. `master` in this case) and objects reachable
This synchronizes your public repository to match the named
branch head (i.e. `master` in this case) and objects reachable
repository. Kernel.org mirror network takes care of the
propagation to other publicly visible machines:
repository. Kernel.org mirror network takes care of the
propagation to other publicly visible machines:
-------------
-git push master.kernel.org:/pub/scm/git/git.git/
-------------
+ git push master.kernel.org:/pub/scm/git/git.git/
Packing your repository
Packing your repository
immutable once they are created, there is a way to optimize the
storage by "packing them together". The command
immutable once they are created, there is a way to optimize the
storage by "packing them together". The command
-------------
-git repack
-------------
+ git repack
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in `.git/objects/??/`
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in `.git/objects/??/`
Once you have packed objects, you do not need to leave the
unpacked objects that are contained in the pack file anymore.
Once you have packed objects, you do not need to leave the
unpacked objects that are contained in the pack file anymore.
-------------
-git prune-packed
-------------
+ git prune-packed
would remove them for you.
would remove them for you.