X-Git-Url: https://git.notmuchmail.org/git?a=blobdiff_plain;f=tour.mdwn;h=53f8f2ca8cc7e7fcec82c06c5a05a9eb1508c00c;hb=6c295b78cc0207247daba5594f62b6ead3dd94e8;hp=7ff65f635f2d5f665232672d5354f581ffa72f93;hpb=44d0c1f81ac57725e18f56431bf37609a68778b2;p=hgbook-git
diff --git a/tour.mdwn b/tour.mdwn
index 7ff65f6..53f8f2c 100644
--- a/tour.mdwn
+++ b/tour.mdwn
@@ -1,11 +1,11 @@
-## Chapter 2
+## Chapter 2
A tour of git: the basics
### 2.0 Copyright
-This document is a modified version originally known as "Distributed
-revision control with Mercurial" and originally authored by Bryan
-OâSullivan. The original document was obtained from
+This document is a modified version of a document originally titled
+"Distributed revision control with Mercurial" and originally authored
+by Bryan OâSullivan. The original document was obtained from
.
Copyright © 2006, 2007 Bryan OâSullivan.
@@ -29,13 +29,23 @@ Changes made by Carl include the following:
* Eliminate line numbers from examples
* Modified to describe git instead of mercurial
-### 2.1 Installing git on your system
+The source of this modified version can be obtained via git:
+
+ git clone git://cworth.org/git/hgbook-git
+
+or
+
+ git clone http://cworth.org/git/hgbook-git
+
+and can be [browsed online](http://git.cworth.org/git/hgbook-git)
+
+### 2.1 Installing git on your system
Prebuilt binary packages of git are available for many popular
operating systems. These make it easy to start using git on your
computer immediately.
-#### 2.1.1 Linux
+#### 2.1.1 Linux
Because each Linux distribution has its own packaging tools, policies,
and rate of development, itâs difficult to give a comprehensive set of
@@ -50,27 +60,27 @@ install git with a single click. The package name to look for is
often git, but is sometimes git-core, (due to an unfortunate name
with git, meaning GNU Interactive Tools).
- * Debian
+ * Debian
apt-get install git-core
- * Fedora Core
+ * Fedora Core
yum install git
- * Gentoo
+ * Gentoo
emerge git
- * OpenSUSE
+ * OpenSUSE
yum install git
- * Ubuntu
+ * Ubuntu
- apt-get install git
+ apt-get install git-core
-#### 2.1.2 Mac OS X
+#### 2.1.2 Mac OS X
A git-core package is available through
[macports](http://macports.org). Once macports is enabled, the command
@@ -78,7 +88,7 @@ to install git is:
port install git-core
-#### 2.1.3 Windows
+#### 2.1.3 Windows
Git has long been available as part of cygwin, and works reasonably
well in that environment. Some people find cygwin a particularly
@@ -90,9 +100,9 @@ installers. These include GitMe, a package to install the entire
development environment necessary to work on improving the msysgit
port of git, and WinGit, a package for installing just git itself
without the development environment, (still in Alpha as of September
-2008).
+2007).
-### 2.2 Getting started
+### 2.2 Getting started
To begin, weâll use the âgit versionâ command to find out whether git
is actually installed properly. Versions 1.5 and newer of git are much
@@ -100,10 +110,10 @@ more friendly to new users than versions 1.4 and older. If you aren't
yet running version 1.5 or newer, it's highly recommended that you
upgrade.
- $ git version
+ $ git version
git version 1.5.3.2
-#### 2.2.1 Built-in help
+#### 2.2.1 Built-in help
Git provides a built-in help system. This is invaluable for those
times when you find yourself stuck trying to remember how to run a
@@ -125,7 +135,7 @@ present and just call out to "man git-"?]
available for git-? And perhaps alos provide a "git -v
help" similar to "hg -v help" for more?]
-### 2.3 Working with a repository
+### 2.3 Working with a repository
In git, everything happens inside a repository. The repository
for a project contains all of the files that âbelong toâ that project,
@@ -136,13 +146,18 @@ a directory tree in your filesystem that git treats as
special. You can rename or delete a repository any time you like,
using either the command line or your file browser.
-#### 2.3.1 Making a local copy of a repository
+#### 2.3.1 Creating a local copy of a remote repository
+
+As suggested, a repository can be copied through normal file-copying
+commands. But git also provides a "git clone" tool for copying a
+repository. This provides a means of copying a repository over the
+network, and is also useful with a local repository since it is much
+more efficient than creating a normal copy, (creating a local clones
+is blazingly fast).
-Copying a repository is just a little bit special. While you could use
-a normal file copying command to make a copy of a repository, itâs
-best to use a built-in command that git provides. This command
-is called âgit cloneâ, because it creates an identical copy of an
-existing repository.
+We've assembled a simple repository that will be used in the examples
+throughout this chapter. Go ahead and clone this repository now so
+that you will be able to follow along:
$ git clone git://cworth.org/git/hello
Initialized empty Git repository in /tmp/hello/.git/
@@ -195,7 +210,7 @@ What this means for now is that weâre free to experiment with our
repository, safe in the knowledge that itâs a private âsandboxâ that
wonât affect anyone else.
-#### 2.3.2 Whatâs in a repository?
+#### 2.3.2 Whatâs in a repository?
When we take a more detailed look inside a repository, we can see that
it contains a directory named .git. This is where git keeps all
@@ -216,7 +231,7 @@ distinction is that the repository contains the history of your
project, while the working directory contains a snapshot of your
project at a particular point in history.
-### 2.4 A tour through history
+### 2.4 A tour through history
One of the first things we might want to do with a new, unfamiliar
repository is understand its history. The âgit logâ command gives us a
@@ -257,7 +272,7 @@ By default, this command prints a brief paragraph of output for each
change to the project that was recorded. In git terminology, we
call each of these recorded events a commit.
-The fields in a record of output from âgit logâ are as follows.
+The fields in a record of output from âgit logâ are as follows.
* commit This field consists of a string of 40 hexadecimal characters.
This is a unique identifier for referring to particular commits.
@@ -279,21 +294,7 @@ The fields in a record of output from âgit logâ are as follows.
The default output printed by âgit logâ is purely a summary; it is
missing a lot of detail.
-Figure [2.1][8] provides a graphical representation of the history of
-the hello repository, to make it a little easier to see which
-direction history is âflowingâ in. Weâll be returning to this figure
-several times in this chapter and the chapter that follows.
-
-* * *
-
-![PIC][9]
-
-Figure 2.1:
-Graphical history of the hello repository
-
-* * *
-
-#### 2.4.1 Commits, revisions, and talking to other people
+#### 2.4.1 Commits, revisions, and talking to other people
As English is a notoriously sloppy language, and computer science has
a hallowed history of terminological confusion (why use one term when
@@ -343,9 +344,9 @@ in the current branch, "HEAD~", refers to the previous commit, and
Another useful syntax is .. which can be used to specify a range of
commits. So "origin..master" specifies everything that has been
-committed to master since it derived from origin.
+committed to master since it diverged from origin.
-#### 2.4.3 Viewing specific revisions
+#### 2.4.3 Viewing specific revisions
You can use "git log" to explore the range syntax just introduced. For
example, to see a list of the most recent 3 revisions you can use
@@ -375,7 +376,7 @@ case):
Besides filtering by commit identifiers, git allows you to easily
filter the log output according to which files (or directories) are
-modified by listing them after "--" wihch is necessary to distinguish
+modified by listing them after "--" which is necessary to distinguish
commit names from file names:
$ git log -- Makefile
@@ -396,10 +397,14 @@ created:
$ git log --since="2 weeks ago" --until="yesterday"
+ [XXX: By default, "git log" displays author dates as "Date"
+ but then uses commit dates when given a --since option. That
+ seems like broken defaults to me. Why the inconsistency?]
+
Another useful option is -n or --max-count which, unsurprisingly,
limits the maximum number of commits to be displayed.
-#### 2.4.3 More detailed information
+#### 2.4.5 More detailed information
While the default information printed by âgit logâ is useful if you
already know what youâre looking for, you may need to see more details
@@ -484,7 +489,7 @@ same output:
return 0;
}
-### 2.5 All about command options
+### 2.5 All about command options
Letâs take a brief break from exploring git commands to discuss
a pattern in the way that they work; you may find this useful to keep
@@ -515,7 +520,7 @@ systems.
Many commands that print output of some kind can be made more quiet by
passing the -q or --quiet options.
-### 2.6 Making and reviewing changes
+### 2.6 Making and reviewing changes
Now that we have a grasp of viewing history in git, letâs take a
look at making some changes and examining them.
@@ -529,7 +534,7 @@ disk space in most cases, too.
$ cd ..
$ git clone hello my-hello
- Initialized empty Git repository in /home/cworth/src/hgbook-git/my-hello/.git/
+ Initialized empty Git repository in /tmp/my-hello/.git/
0 blocks
[XXX We say "empty" here, (presumably from the git-init part),
@@ -564,7 +569,7 @@ scripted example this way. Since youâre not under the same constraint,
you probably wonât want to use sed; simply use your preferred text
editor to do the same thing.)
- $ sed -i '/printf/a\\tprintf("hello again!\\n");' hello.c
+ $ sed -i '/printf/a\\tprintf("hello again!\\n");' hello.c
The âgit statusâ command will tell us what git knows about the files
in the repository.
@@ -605,7 +610,7 @@ this, we use the âgit diffâ command.
return 0;
}
-### 2.7 Recording changes in a new commit
+### 2.7 Recording changes in a new commit
We can modify files, build and test our changes, and use âgit statusâ
and âgit diffâ to review our changes, until weâre satisfied with what
@@ -615,7 +620,7 @@ record our work in a new commit.
The âgit commitâ command lets us create a new changeset; weâll usually
refer to this as âmaking a commitâ or âcommittingâ.
-#### 2.7.1 Setting up a username
+#### 2.7.1 Setting up a username
When you try to run âgit commitâ for the first time, it might not do
exactly what you want. Git records your name and address with each
@@ -683,7 +688,7 @@ the files directly. Use your favorite editor to create a file called
then it will be there already). The initial contents of your
.gitconfig should look like this.
- # This is a git configuration file.
+ # This is a git configuration file.
[user]
name = Your Name
email = you@example.com
@@ -713,7 +718,7 @@ requirement that the email address actually be valid, and perhaps it's
useful to be reminded which machine was used to create particular
commits.
-#### 2.7.2 Writing a commit message
+#### 2.7.2 Writing a commit message
When we commit a change, git drops us into a text editor to
enter a message that will describe the modifications weâve made in
@@ -723,12 +728,18 @@ after weâve finished committing.
$ git commit -a
-Note: The -a on the command-line instructs git to commit all changes
-to tracked files. Without this, "git commit" will only commit changes
-that have been previously staged for committing with "git add
-file". The most common usage is to commit with "git commit -a" and
-only use "git add file; git commit" when there is a need to commit
-only some subset of changes that have been made.
+Note: The -a on the command-line instructs git to commit the new
+content of *all* tracked files that have been modified. This is a
+convenience over explicitly listing filenames to be committed on the
+"git commit" command line. It is useful to use "git commit "
+when there is a need to commit only some subset of the files that have
+been modified.
+
+If new files need to be committed for the first time, just use "git
+add " before "git commit -a". If a file needs to be removed,
+just remove it as normal before committing and "git commit -a" will
+notice that---it does not need to be explicitly told about the
+removal.
The editor that the âgit commitâ command drops us into will contain an
empty line, followed by a number of lines starting with â#â.
@@ -747,7 +758,7 @@ git ignores the lines that start with â#â; it uses them only
to tell us which files itâs recording changes to. Modifying or
deleting these lines has no effect.
-#### 2.7.3 Writing a good commit message
+#### 2.7.3 Writing a good commit message
A good commit message will generally have a single line that
summarizes the commit, a blank line, and then one or more pargraphs
@@ -778,14 +789,14 @@ My personal preference is for short, but informative, commit messages
that tell me something that I canât figure out with a quick glance at
the output of âgit log -p".
-#### 2.7.4 Aborting a commit
+#### 2.7.4 Aborting a commit
If you decide that you donât want to commit while in the middle of
editing a commit message, simply exit from your editor without saving
the file that itâs editing. This will cause nothing to happen to
either the repository or the working directory.
-#### 2.7.5 Admiring our new handiwork
+#### 2.7.5 Admiring our new handiwork
Once weâve finished the commit, we can use the âgit showâ command to
display the commit we just created. As discussed previously, this
@@ -909,242 +920,228 @@ the --amend example to not teach bad habits like I did above. [Note:
All this bad-habit stuff was introduced by me, and was not present in
Bryan's original chapter. -Carl]
-### 2.8 Sharing changes
+### 2.8 Sharing changes
-We mentioned earlier that repositories in Mercurial are
-self-contained. This means that the changeset we just created exists
+We mentioned earlier that repositories in git are
+self-contained. This means that the commit we just created exists
only in our my-hello repository. Letâs look at a few ways that we can
propagate this change into other repositories.
-#### 2.8.1 Pulling changes from another repository
+#### 2.8.1 Pulling changes from another repository
To get started, letâs clone our original hello repository, which does
not contain the change we just committed. Weâll call our temporary
repository hello-pull.
- $ cd ..
- $ hg clone hello hello-pull
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-Weâll use the âhg pullâ command to bring changes from my-hello into
-hello-pull. However, blindly pulling unknown changes into a repository
-is a somewhat scary prospect. Mercurial provides the âhg incomingâ
-command to tell us what changes the âhg pullâ command would pull into
-the repository, without actually pulling the changes in.
-
- $ cd hello-pull
- $ hg incoming ../my-hello
- comparing with ../my-hello
- searching for changes
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
-
-
-(Of course, someone could cause more changesets to appear in the
-repository that we ran âhg incomingâ in, before we get a chance to âhg
-pullâ the changes, so that we could end up pulling changes that we
-didnât expect.)
-
-Bringing changes into a repository is a simple matter of running the
-âhg pullâ command, and telling it which repository to pull from.
+ $ cd ..
+ $ git clone hello hello-pull
+ Initialized empty Git repository in /tmp/hello-pull/.git/
+ 0 blocks
- $ hg tip
- changeset: 4:b57f9a090b62
- tag: tip
- user: Bryan O'Sullivan
- date: Tue Sep 06 15:43:07 2005 -0700
- summary: Trim comments.
-
- $ hg pull ../my-hello
- pulling from ../my-hello
- searching for changes
- adding changesets
- adding manifests
- adding file changes
- added 1 changesets with 1 changes to 1 files
- (run 'hg update' to get a working copy)
- $ hg tip
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
-
+We could use the âgit pullâ command to apply changes from my-hello to
+our master branch in hello-pull. However, blindly pulling unknown
+changes into a repository is a somewhat scary prospect. The "git pull"
+command is coneptually the combination of two commands, "git fetch"
+and "git merge"; we can run those separately to examine the changes
+before applying them locally. First we do the fetch:
-As you can see from the before-and-after output of âhg tipâ, we have
-successfully pulled changes into our repository. There remains one
-step before we can see these changes in the working directory.
-
-#### 2.8.2 Updating the working directory
-
-We have so far glossed over the relationship between a repository and
-its working directory. The âhg pullâ command that we ran in
-section [2.8.1][12] brought changes into the repository, but if we
-check, thereâs no sign of those changes in the working directory. This
-is because âhg pullâ does not (by default) touch the working
-directory. Instead, we use the âhg updateâ command to do this.
-
- $ grep printf hello.c
- printf("hello, world!â");
- $ hg update tip
- 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
- $ grep printf hello.c
- printf("hello, world!â");
- printf("hello again!ân");
-
-It might seem a bit strange that âhg pullâ doesnât update the working
-directory automatically. Thereâs actually a good reason for this: you
-can use âhg updateâ to update the working directory to the state it
-was in at any revision in the history of the repository. If you had
-the working directory updated to an old revisionâto hunt down the
-origin of a bug, sayâand ran a âhg pullâ which automatically updated
-the working directory to a new revision, you might not be terribly
-happy.
-
-However, since pull-then-update is such a common thing to do,
-Mercurial lets you combine the two by passing the -u option to âhg
-pullâ.
-
- hg pull -u
-
-If you look back at the output of âhg pullâ in section [2.8.1][12]
-when we ran it without -u, you can see that it printed a helpful
-reminder that weâd have to take an explicit step to update the working
-directory:
-
- (run 'hg update' to get a working copy)
-
-To find out what revision the working directory is at, use the âhg
-parentsâ command.
-
- $ hg parents
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
-
-
-If you look back at figure [2.1][8], youâll see arrows connecting each
-changeset. The node that the arrow leads from in each case is a
-parent, and the node that the arrow leads to is its child. The working
-directory has a parent in just the same way; this is the changeset
-that the working directory currently contains.
-
-To update the working directory to a particular revision, give a
-revision number or changeset ID to the âhg updateâ command.
-
- $ hg update 2
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
- $ hg parents
- changeset: 2:057d3c2d823c
- user: Bryan O'Sullivan
- date: Tue Sep 06 13:15:43 2005 -0700
- summary: Introduce a typo into hello.c.
-
- $ hg update
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-If you omit an explicit revision, âhg updateâ will update to the tip
-revision, as shown by the second call to âhg updateâ in the example
-above.
-
-#### 2.8.3 Pushing changes to another repository
-
-Mercurial lets us push changes to another repository, from the
-repository weâre currently visiting. As with the example of âhg pullâ
-above, weâll create a temporary repository to push our changes into.
-
- $ cd ..
- $ hg clone hello hello-push
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-The âhg outgoingâ command tells us what changes would be pushed into
-another repository.
-
- $ cd my-hello
- $ hg outgoing ../hello-push
- comparing with ../hello-push
- searching for changes
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ cd hello-pull
+ $ git fetch ../my-hello
+ remote: Generating pack...
+ Unpacking 3 objects...
+ 100% (3/3) done
+ remote: Done counting 5 objects.
+ Result has 3 objects.
+ Deltifying 3 objects...
+ 100% remote: (3/3) done
+ Total 3 (delta 1), reused 0 (delta 0)
+
+The fetched commits (or commit in this case) are available as the name
+FETCH_HEAD. [XXX: Shouldn't git-fetch print that name out to the user
+if the user didn't provide a specific branch name to fetch into.] And
+the difference between what we had before and what exists on
+FETCH_HEAD can easily be examined with the ..FETCH_HEAD range
+notation:
+
+ $ git log ..FETCH_HEAD
+ commit 839b58d021c618bd0e1d336d4d5878a0082672e6
+ Author: Carl Worth
+ Date: Thu Sep 27 23:55:00 2007 -0700
+ Added an extra line of output and fixed the typo bug.
-And the âhg pushâ command does the actual push.
+Since these commits actually exist in the local repository now, we
+don't need to fetch or pull them from the remote repository again---we
+can now use "git merge" to apply the previously fetched commits. (A
+mercurial user might notice here that git does not have the race
+condition between "hg incoming" and "hg pull" that mercurial has since
+the commits are fetched only once.)
+
+ $ git merge FETCH_HEAD
+ Updating a1a0e8b..839b58d
+ Fast forward
+ hello.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+Notice that "git merge" reports that our branch pointer has been
+updated from a1a0e8b to 839b58d. Also, this is a "fast forward"
+meaning that the new commits are a linear sequence on top of the
+commit we already hand. In other words, there wasn't any divergence
+between these two repositories so no actual "merge" commit was
+created.
+
+This separation of fetch and merge is useful when you need to
+carefully review some changes before applying them. But often you're
+in a situation where you know you trust the remote repository and you
+simply want to pull those changes as conveniently as possible, (no
+extra commands, no typing a magic name like FETCH_HEAD). This is the
+case when the tracking upstream development of a project with git. And
+in that case, the above steps are as simple as just executing "git
+pull". So let's repeat all that the simpler way:
- $ hg push ../hello-push
- pushing to ../hello-push
- searching for changes
- adding changesets
- adding manifests
- adding file changes
- added 1 changesets with 1 changes to 1 files
+ $ cd ..
+ $ git clone hello hello-tracking
+ Initialized empty Git repository in /tmp/hello-tracking/.git/
+ 0 blocks
+ $ cd hello-tracking
+ $ git pull ../my-hello
+ remote: Generating pack...
+ remote: Done counting 5 objects.
+ Result has 3 objects.
+ Deltifying 3 objects...
+ Unpacking 3 objects...
+ remote: 100% (3/3) done
+ Total 3 (delta 1), reused 0 (delta 0)
+ 100% (3/3) done
+ Updating a1a0e8b..839b58d
+ Fast forward
+ hello.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+It should be plain to see that the "git pull" command really did the
+combined sequence of "git fetch" and "git merge". Also, if you want to
+pull from the same repository you cloned from originally, (which is
+the common case for the upstream-tracking scenario), then "git pull"
+with no explicit repository is suffcient, and it will default to
+pulling from the same repository as the original clone.
+
+[XXX: The structure of the preceding section follows that of the
+original hgbook. But an alternate structure that arranged to pull from
+the originally cloned repository (as would be common) would allow for
+more straightforward use of git's features. For example, instead of
+the silly FETCH_HEAD stuff it would allow for "git fetch" and "git log
+master..origin" to be a very nice replacement for "hg
+incoming". Similarly, below, "git log origin..master" would make a
+nice replacement for "hg outgoing" which is something I didn't offer
+at all. One could also use git's remotes with the myriad repositories
+as used here, but it would require doing things like "git remote add
+ ../hello-pull" and that seems like a bit much to introduce
+for a turorial of this level. If nothing else, if the above section
+seems a little intimidating, understand that it's because things are
+not presented in the most natural "git way", (and I'm a little too
+tired to fix it tonight).]
+
+Note: Mercurial users who are reading this might wonder if there's a
+need for the equivalent of "hg update" after doing a "git pull". And
+the answer is no. Unlike mercurial, "git pull" and "git merge" will
+automatically update the workind-directory files as necessary.
+
+#### 2.8.2 Checking out previous revisions
+
+It's often useful to examine the working-tree state of some specific
+revision other than the tip of some branch. For example, maybe you
+would like to build a particular tagged version, or maybe you'd like
+to test the behavior of the code before a particular change was
+introduced. To do this, use "git checkout" and pass it the name of any
+revision, (with a branch name, a tag name, or any other commit
+identifier). For example, to examine our project before the original
+typo was introduced:
+
+ $ git checkout 0a633bf5
+ Note: moving to "0a633bf5" which isn't a local branch
+ If you want to create a new branch from this checkout, you may do so
+ (now or later) by using -b with the checkout command again. Example:
+ git checkout -b
+ HEAD is now at 0a633bf... Create a makefile
+
+The note that git gives us is to indicate that we are checking out a
+non-branch revision. This is perfectly fine if we are just exploring
+history, but if we actually wanted to use this revision as the basis
+for new commits, we would first have to create a new branch name as it
+describes.
+
+If we were to use "git checkout" with a branch name, then that would
+change the current branch, (meaning that any new commits would advance
+that branch pointer).
+
+For now, let's return back to the tip of the master branch by just
+checking it out again:
+
+ $ git checkout master
+ Previous HEAD position was 0a633bf... Create a makefile
+ Switched to branch "master"
+
+#### 2.8.3 Pushing changes to another repository
+
+Git lets us push changes to another repository, from the repository
+weâre currently visiting. As with previous examples, above, weâll
+first create a temporary repository to push our changes into. But
+instead of using "git clone", this time we'll use "git init" to make a
+repository from an empty directory. We do this to create a "bare"
+repository which is simply a repository that has no working-directory
+files associated with it. In general, you should only push to bare
+repositories.
-As with âhg pullâ, the âhg pushâ command does not update the working
-directory in the repository that itâs pushing changes into. (Unlike
-âhg pullâ, âhg pushâ does not provide a -u option that updates the
-other repositoryâs working directory.)
+ $ cd ..
+ $ mkdir hello-push
+ $ cd hello-push
+ $ git --bare init
+ Initialized empty Git repository in /tmp/hello-push/
+
+And then we'll go back to our my-hello repository to perform the
+push. Since this is our very first push into this repository we need
+to tell git which branches to push. The easiest way to do this is to
+use --all to indicate all branches:
+
+ $ cd ../my-hello
+ $ git push ../hello-push --all
+ updating 'refs/heads/master'
+ from 0000000000000000000000000000000000000000
+ to 839b58d021c618bd0e1d336d4d5878a0082672e6
+ Generating pack...
+ Done counting 18 objects.
+ Deltifying 18 objects...
+ 100% (18/18) done
+ Writing 18 objects...
+ 100% (18/18) done
+ Total 18 (delta 3), reused 0 (delta 0)
+ Unpacking 18 objects...
+ 100% (18/18) done
+ refs/heads/master: 0000000000000000000000000000000000000000 -> 839b58d021c618bd0e1d336d4d5878a0082672e6
+
+For subsequent pushes we don't need to specify --all as "git push"
+will push all branches that exist in both the local and remote
+repositories.
What happens if we try to pull or push changes and the receiving
repository already has those changes? Nothing too exciting.
- $ hg push ../hello-push
- pushing to ../hello-push
- searching for changes
- no changes found
+ $ git push ../hello-push
+ Everything up-to-date
-#### 2.8.4 Sharing changes over a network
+#### 2.8.4 Sharing changes over a network
The commands we have covered in the previous few sections are not
limited to working with local repositories. Each works in exactly the
-same fashion over a network connection; simply pass in a URL instead
-of a local path.
-
- $ hg outgoing http://hg.serpentine.com/tutorial/hello
- comparing with http://hg.serpentine.com/tutorial/hello
- searching for changes
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
-
+same fashion over a network connection; simply pass in a URL or an ssh
+host:/path/name specification instead of a local path.
-In this example, we can see what changes we could push to the remote
-repository, but the repository is understandably not set up to let
-anonymous users push to it.
-
- $ hg push http://hg.serpentine.com/tutorial/hello
- pushing to http://hg.serpentine.com/tutorial/hello
- searching for changes
- ssl required
-
- [1]: http://hgbook.red-bean.com/hgbookch3.html
- [2]: http://hgbook.red-bean.com/hgbookch1.html
- [3]: http://hgbook.red-bean.com/hgbookch1.html#tailhgbookch1.html
- [4]: #tailhgbookch2.html
- [5]: http://hgbook.red-bean.com/hgbook.html#hgbookch2.html
- [6]: http://mercurial.berkwood.com/
- [7]: http://hgbook.red-bean.com/hgbookli4.html#Xweb:macpython
- [8]: #x6-340581
- [9]: hgbookch2_files/tour-history.png
- [10]: http://hgbook.red-bean.com/hgbookch12.html#x16-27100012.4
- [11]: #x6-420002.7.1
- [12]: #x6-490002.8.1
- [13]: http://hgbook.red-bean.com/hgbookch2.html
-
-## Appendix D
+## Appendix D
Open Publication License
Version 1.0, 8 June 1999
-### D.1 Requirements on both unmodified and modified versions
+### D.1 Requirements on both unmodified and modified versions
The Open Publication works may be reproduced and distributed in whole
or in part, in any medium physical or electronic, provided that the
@@ -1173,12 +1170,12 @@ outer surfaces of the book the original publisherâs name shall be as
large as the title of the work and cited as possessive with respect to
the title.
-### D.2 Copyright
+### D.2 Copyright
The copyright to each Open Publication is owned by its author(s) or
designee.
-### D.3 Scope of license
+### D.3 Scope of license
The following license terms apply to all Open Publication works,
unless otherwise explicitly stated in the document.
@@ -1198,7 +1195,7 @@ without warranty of any kind, express or implied, including, but not
limited to, the implied warranties of merchantability and fitness for
a particular purpose or a warranty of non-infringement.
-### D.4 Requirements on modified works
+### D.4 Requirements on modified works
All modified versions of documents covered by this license, including
translations, anthologies, compilations and partial documents, must
@@ -1215,7 +1212,7 @@ meet the following requirements:
assert or imply endorsement of the resulting document without the
original authorâs (or authorsâ) permission.
-### D.5 Good-practice recommendations
+### D.5 Good-practice recommendations
In addition to the requirements of this license, it is requested from
and strongly recommended of redistributors that:
@@ -1234,7 +1231,7 @@ and strongly recommended of redistributors that:
CD-ROM expression of an Open Publication-licensed work to its
author(s).
-### D.6 License options
+### D.6 License options
The author(s) and/or publisher of an Open Publication-licensed
document may elect certain options by appending language to the