![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 5f41a2d026e9dfa267aa278cf0d083dbe4132e72..03736bbcd3ebfd5e1cbe6a006acb2b31411af527 100644 (file)
importantly, it is a globally unique name for this commit: so if you
tell somebody else the object name (for example in email), then you are
guaranteed that name will refer to the same commit in their repository
importantly, it is a globally unique name for this commit: so if you
tell somebody else the object name (for example in email), then you are
guaranteed that name will refer to the same commit in their repository
-that you it does in yours (assuming their repository has that commit at
+that it does in yours (assuming their repository has that commit at
all).
Understanding history: commits, parents, and reachability
all).
Understanding history: commits, parents, and reachability
that Y is a descendent of X, or that there is a chain of parents
leading from commit Y to commit X.
that Y is a descendent of X, or that there is a chain of parents
leading from commit Y to commit X.
-Undestanding history: History diagrams
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Understanding history: History diagrams
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We will sometimes represent git history using diagrams like the one
below. Commits are shown as "o", and the links between them with
We will sometimes represent git history using diagrams like the one
below. Commits are shown as "o", and the links between them with
Git provides extremely flexible and fast tools for exploring the
history of a project.
Git provides extremely flexible and fast tools for exploring the
history of a project.
-We start with one specialized tool which is useful for finding the
+We start with one specialized tool that is useful for finding the
commit that introduced a bug into a project.
How to use bisect to find a regression
commit that introduced a bug into a project.
How to use bisect to find a regression
We have seen several ways of naming commits already:
We have seen several ways of naming commits already:
- - 40-hexdigit SHA1 id
+ - 40-hexdigit object name
- branch name: refers to the commit at the head of the given
branch
- tag name: refers to the commit pointed to by the given tag
- branch name: refers to the commit at the head of the given
branch
- tag name: refers to the commit pointed to by the given tag
name revisions. Some examples:
-------------------------------------------------
name revisions. Some examples:
-------------------------------------------------
-$ git show fb47ddb2 # the first few characters of the SHA1 id
+$ git show fb47ddb2 # the first few characters of the object name
# are usually enough to specify it uniquely
$ git show HEAD^ # the parent of the HEAD commit
$ git show HEAD^^ # the grandparent
# are usually enough to specify it uniquely
$ git show HEAD^ # the parent of the HEAD commit
$ git show HEAD^^ # the grandparent
branch.
The gitlink:git-rev-parse[1] command is a low-level command that is
branch.
The gitlink:git-rev-parse[1] command is a low-level command that is
-occasionally useful for translating some name for a commit to the SHA1 id for
-that commit:
+occasionally useful for translating some name for a commit to the object
+name for that commit:
-------------------------------------------------
$ git rev-parse origin
-------------------------------------------------
$ git rev-parse origin
Note that git log starts with the most recent commit and works
backwards through the parents; however, since git history can contain
Note that git log starts with the most recent commit and works
backwards through the parents; however, since git history can contain
-multiple independant lines of development, the particular order that
+multiple independent lines of development, the particular order that
commits are listed in may be somewhat arbitrary.
Generating diffs
commits are listed in may be somewhat arbitrary.
Generating diffs
will tell you whether the contents of the project are the same at the
two branches; in theory, however, it's possible that the same project
contents could have been arrived at by two different historical
will tell you whether the contents of the project are the same at the
two branches; in theory, however, it's possible that the same project
contents could have been arrived at by two different historical
-routes. You could compare the SHA1 id's:
+routes. You could compare the object names:
-------------------------------------------------
$ git rev-list origin
-------------------------------------------------
$ git rev-list origin
-------------------------------------------------
and git will prompt you for a commit message and then create the new
-------------------------------------------------
and git will prompt you for a commit message and then create the new
-commmit. Check to make sure it looks like what you expected with
+commit. Check to make sure it looks like what you expected with
-------------------------------------------------
$ git show
-------------------------------------------------
$ git show
-------------------------------------------------
The reflogs are kept by default for 30 days, after which they may be
-------------------------------------------------
The reflogs are kept by default for 30 days, after which they may be
-pruned. See gitlink:git-reflink[1] and gitlink:git-gc[1] to learn
+pruned. See gitlink:git-reflog[1] and gitlink:git-gc[1] to learn
how to control this pruning, and see the "SPECIFYING REVISIONS"
section of gitlink:git-rev-parse[1] for details.
how to control this pruning, and see the "SPECIFYING REVISIONS"
section of gitlink:git-rev-parse[1] for details.
...
-------------------------------------------------
...
-------------------------------------------------
-and watch for output that mentions "dangling commits". You can examine
+You can examine
one of those dangling commits with, for example,
------------------------------------------------
one of those dangling commits with, for example,
------------------------------------------------
If you just have a few changes, the simplest way to submit them may
just be to send them as patches in email:
If you just have a few changes, the simplest way to submit them may
just be to send them as patches in email:
-First, use gitlink:git-format-patches[1]; for example:
+First, use gitlink:git-format-patch[1]; for example:
-------------------------------------------------
$ git format-patch origin
-------------------------------------------------
$ git format-patch origin
Allow web browsing of a repository
----------------------------------
Allow web browsing of a repository
----------------------------------
-TODO: Brief setup-instructions for gitweb
+The gitweb cgi script provides users an easy way to browse your
+project's files and history without having to install git; see the file
+gitweb/README in the git source tree for instructions on setting it up.
Examples
--------
Examples
--------
$ git-merge-index git-merge-one-file hello.c
-------------------------------------------------
$ git-merge-index git-merge-one-file hello.c
-------------------------------------------------
-and that is what higher level `git resolve` is implemented with.
+and that is what higher level `git merge -s resolve` is implemented with.
How git stores objects efficiently: pack files
----------------------------------------------
How git stores objects efficiently: pack files
----------------------------------------------
allow people to get to important topics without necessarily reading
everything in between.
allow people to get to important topics without necessarily reading
everything in between.
+Say something about .gitignore.
+
Scan Documentation/ for other stuff left out; in particular:
howto's
some of technical/?
hooks
Scan Documentation/ for other stuff left out; in particular:
howto's
some of technical/?
hooks
- etc.
+ list of commands in gitlink:git[1]
Scan email archives for other stuff left out
Scan email archives for other stuff left out
Document shallow clones? See draft 1.5.0 release notes for some
documentation.
Document shallow clones? See draft 1.5.0 release notes for some
documentation.
-Add a sectin on working with other version control systems, including
+Add a section on working with other version control systems, including
CVS, Subversion, and just imports of series of release tarballs.
CVS, Subversion, and just imports of series of release tarballs.
+More details on gitweb?
+
+Write a chapter on using plumbing and writing scripts.