summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: f22fd75)
raw | patch | inline | side by side (parent: f22fd75)
author | Junio C Hamano <junkio@cox.net> | |
Mon, 6 Feb 2006 20:27:33 +0000 (12:27 -0800) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Mon, 6 Feb 2006 20:27:33 +0000 (12:27 -0800) |
We still talked about HEAD symlinks but these days we use
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/core-tutorial.txt | patch | blob | history |
index 4513ad635f2cbea21e4d624ec2578a3d59148759..c3eaa38b54f0f171791a46d13752d04935434f6d 100644 (file)
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 file called `HEAD`, that has `ref: refs/heads/master` in it.
+ This is similar to a symbolic link and points at
+ `refs/heads/master` relative to the `HEAD` file.
+
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
repository.
One note: the special `master` head is the default branch, which is
-why the `.git/HEAD` file was created as a symlink to it even if it
+why the `.git/HEAD` file was created points to it even if it
doesn't yet exist. Basically, the `HEAD` link is supposed to always
point to the branch you are working on right now, and you always
start out expecting to work on the `master` branch.
$ echo "Silly example" >example
------------------------------------------------
-you have now created two files in your working tree (aka 'working directory'), but to
-actually check in your hard work, you will have to go through two steps:
+you have now created two files in your working tree (aka 'working directory'),
+but to actually check in your hard work, you will have to go through two steps:
- fill in the 'index' file (aka 'cache') with the information about your
working tree state.
.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
----------------
-which correspond with the objects with names of 557db... and f24c7..
-respectively.
+which correspond with the objects with names of `557db...` and
+`f24c7...` respectively.
If you want to, you can use `git-cat-file` to look at those objects, but
you'll have to use the object name, not the filename of the object:
$ git-cat-file "blob" 557db03
----------------
-which will print out "Hello World". The object 557db03 is nothing
+which will print out "Hello World". The object `557db03` is nothing
more than the contents of your file `hello`.
[NOTE]
+-----------+
============
-More interestingly, you can also give `git-diff-tree` the `-v` flag, which
-tells it to also show the commit message and author and date of the
+More interestingly, you can also give `git-diff-tree` the `--pretty` flag,
+which tells it to also show the commit message and author and date of the
commit, and you can tell it to show a whole series of diffs.
Alternatively, you can tell it to be "silent", and not show the diffs at
all, but just show the actual commit message.
(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
-------------
-
-will tell you where it's pointing (Note that on platforms with bad or no
-symlink support, you have to execute
-
------------
$ cat .git/HEAD
------------
-instead). To get the list of branches you have, you can say
+will tell you where it's pointing. To get the list of branches
+you have, you can say
------------
$ git branch
Here, we just added another line to `hello`, and we used a shorthand for
doing both `git-update-index hello` and `git commit` by just giving the
-filename directly to `git commit`. The `-m` flag is to give the
+filename directly to `git commit`, with an `-i` flag (it tells
+git to 'include' that file in addition to what you have done to
+the index file so far when making the commit). The `-m` flag is to give the
commit log message from the command line.
Now, to make it a bit more interesting, let's assume that somebody else
...
Auto-merging hello
CONFLICT (content): Merge conflict in hello
- Automatic merge failed/prevented; fix up by hand
+ Automatic merge failed; fix up by hand
----------------
which is way too verbose, but it basically tells you that it failed the
environment, is `git show-branch`.
------------------------------------------------
-$ git show-branch master mybranch
+$ git show-branch --topo-order master mybranch
* [master] Merge work in mybranch
! [mybranch] Some work.
--
----------------
Updating from ae3a2da... to a80b4aa....
+Fast forward
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)