-## Chapter 2
+## Chapter 2
A tour of git: the basics
### 2.0 Copyright
* Debian
- apt-get install git-core
+ apt-get install git-core
* Fedora Core
- yum install git
+ yum install git
* Gentoo
- emerge git
+ emerge git
* OpenSUSE
- yum install git
+ yum install git
* Ubuntu
- apt-get install git
+ apt-get install git
#### 2.1.2 Mac OS X
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
repository is understand its history. The “hg log” command gives us a
view of history.
- $ hg log
- changeset: 4:b57f9a090b62
- tag: tip
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 15:43:07 2005 -0700
- summary: Trim comments.
+ $ hg log
+ changeset: 4:b57f9a090b62
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 15:43:07 2005 -0700
+ summary: Trim comments.
- changeset: 3:ff5d7b70a2a9
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:58 2005 -0700
- summary: Get make to generate the final binary from a .o file.
+ changeset: 3:ff5d7b70a2a9
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:58 2005 -0700
+ summary: Get make to generate the final binary from a .o file.
- changeset: 2:057d3c2d823c
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:43 2005 -0700
- summary: Introduce a typo into hello.c.
+ changeset: 2:057d3c2d823c
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:43 2005 -0700
+ summary: Introduce a typo into hello.c.
- changeset: 1:82e55d328c8c
- user: mpm@selenic.com
- date: Fri Aug 26 01:21:28 2005 -0700
- summary: Create a makefile
+ changeset: 1:82e55d328c8c
+ user: mpm@selenic.com
+ date: Fri Aug 26 01:21:28 2005 -0700
+ summary: Create a makefile
- changeset: 0:0a04b987be5a
- user: mpm@selenic.com
- date: Fri Aug 26 01:20:50 2005 -0700
- summary: Create a standard "hello, world" program
+ changeset: 0:0a04b987be5a
+ user: mpm@selenic.com
+ date: Fri Aug 26 01:20:50 2005 -0700
+ summary: Create a standard "hello, world" program
By default, this command prints a brief paragraph of output for each
The default output printed by “hg log” is purely a summary; it is
missing a lot of detail.
-Figure [2.1][8] provides a graphical representation of the history of
+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:
+Figure 2.1:
Graphical history of the hello repository
* * *
changeset is referred to as a “revision” or a “rev”.
While it doesn’t matter what word you use to refer to the concept of
-“a changeset”, the identifier that you use to refer to “a specific
+“a changeset”, the identifier that you use to refer to “a specific
changeset” is of great importance. Recall that the changeset field in
the output from “hg log” identifies a changeset using both a number
and a hexadecimal string.
repository.
This distinction is important. If you send someone an email talking
-about “revision 33”, there’s a high likelihood that their revision 33
+about “revision 33”, there’s a high likelihood that their revision 33
will not be the same as yours. The reason for this is that a revision
number depends on the order in which changes arrived in a repository,
and there is no guarantee that the same changes will happen in the
changeset identifier, and you can provide as many revisions as you
want.
- $ hg log -r 3
- changeset: 3:ff5d7b70a2a9
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:58 2005 -0700
- summary: Get make to generate the final binary from a .o file.
+ $ hg log -r 3
+ changeset: 3:ff5d7b70a2a9
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:58 2005 -0700
+ summary: Get make to generate the final binary from a .o file.
- $ hg log -r ff5d7b70a2a9
- changeset: 3:ff5d7b70a2a9
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:58 2005 -0700
- summary: Get make to generate the final binary from a .o file.
+ $ hg log -r ff5d7b70a2a9
+ changeset: 3:ff5d7b70a2a9
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:58 2005 -0700
+ summary: Get make to generate the final binary from a .o file.
- $ hg log -r 1 -r 4
- changeset: 1:82e55d328c8c
- user: mpm@selenic.com
- date: Fri Aug 26 01:21:28 2005 -0700
- summary: Create a makefile
+ $ hg log -r 1 -r 4
+ changeset: 1:82e55d328c8c
+ user: mpm@selenic.com
+ date: Fri Aug 26 01:21:28 2005 -0700
+ summary: Create a makefile
- changeset: 4:b57f9a090b62
- tag: tip
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 15:43:07 2005 -0700
- summary: Trim comments.
+ changeset: 4:b57f9a090b62
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 15:43:07 2005 -0700
+ summary: Trim comments.
If you want to see the history of several revisions without having to
list each one, you can use range notation; this lets you express the
idea “I want all revisions between a and b, inclusive”.
- $ hg log -r 2:4
- changeset: 2:057d3c2d823c
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:43 2005 -0700
- summary: Introduce a typo into hello.c.
+ $ hg log -r 2:4
+ changeset: 2:057d3c2d823c
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:43 2005 -0700
+ summary: Introduce a typo into hello.c.
- changeset: 3:ff5d7b70a2a9
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:58 2005 -0700
- summary: Get make to generate the final binary from a .o file.
+ changeset: 3:ff5d7b70a2a9
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:58 2005 -0700
+ summary: Get make to generate the final binary from a .o file.
- changeset: 4:b57f9a090b62
- tag: tip
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 15:43:07 2005 -0700
- summary: Trim comments.
+ changeset: 4:b57f9a090b62
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 15:43:07 2005 -0700
+ summary: Trim comments.
Mercurial also honours the order in which you specify revisions, so
for. The “hg log” command’s -v (or --verbose) option gives you this
extra detail.
- $ hg log -v -r 3
- changeset: 3:ff5d7b70a2a9
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:58 2005 -0700
- files: Makefile
+ $ hg log -v -r 3
+ changeset: 3:ff5d7b70a2a9
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:58 2005 -0700
+ files: Makefile
description:
- Get make to generate the final binary from a .o file.
+ Get make to generate the final binary from a .o file.
If you want to see both the description and content of a change, add
the -p (or --patch) option. This displays the content of a change as a
unified diff (if you’ve never seen a unified diff before, see
-section [12.4][10] for an overview).
+section [12.4][10] for an overview).
- $ hg log -v -p -r 2
- changeset: 2:057d3c2d823c
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 13:15:43 2005 -0700
- files: hello.c
+ $ hg log -v -p -r 2
+ changeset: 2:057d3c2d823c
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Tue Sep 06 13:15:43 2005 -0700
+ files: hello.c
description:
- Introduce a typo into hello.c.
+ Introduce a typo into hello.c.
- diff -r 82e55d328c8c -r 057d3c2d823c hello.c
- --- a/hello.c Fri Aug 26 01:21:28 2005 -0700
- +++ b/hello.c Tue Sep 06 13:15:43 2005 -0700
- @@ -11,6 +11,6 @@
+ diff -r 82e55d328c8c -r 057d3c2d823c hello.c
+ --- a/hello.c Fri Aug 26 01:21:28 2005 -0700
+ +++ b/hello.c Tue Sep 06 13:15:43 2005 -0700
+ @@ -11,6 +11,6 @@
- int main(int argc, char ⋆⋆argv)
+ int main(int argc, char ⋆⋆argv)
{
- - printf("hello, world!∖n");
- + printf("hello, world!∖");
- return 0;
+ - printf("hello, world!∖n");
+ + printf("hello, world!∖");
+ return 0;
}
* Most options have short names, too. Instead of --rev, we can use
-r. (The reason that some options don’t have short names is that
the options in question are rarely used.)
- * Long options start with two dashes (e.g. --rev), while short
- options start with one (e.g. -r).
+ * Long options start with two dashes (e.g. --rev), while short
+ options start with one (e.g. -r).
* Option naming and usage is consistent across commands. For
- example, every command that lets you specify a changeset ID or
+ example, every command that lets you specify a changeset ID or
revision number accepts both -r and --rev arguments.
In the examples throughout this book, I use short options instead of
cloning over the network, and cloning a local repository uses less
disk space in most cases, too.
- $ cd ..
- $ hg clone hello my-hello
- 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
- $ cd my-hello
+ $ cd ..
+ $ hg clone hello my-hello
+ 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+ $ cd my-hello
As an aside, it’s often good practice to keep a “pristine” copy of a
remote repository around, which you can then make temporary clones of
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
Mercurial’s “hg status” command will tell us what Mercurial knows
about the files in the repository.
- $ ls
- Makefile hello.c
- $ hg status
- M hello.c
+ $ ls
+ Makefile hello.c
+ $ hg status
+ M hello.c
The “hg status” command prints no output for some files, but a line
starting with “M” for hello.c. Unless you tell it to, “hg status” will
might prefer to know exactly what changes we’ve made to it. To do
this, we use the “hg diff” command.
- $ hg diff
- diff -r b57f9a090b62 hello.c
- --- a/hello.c Tue Sep 06 15:43:07 2005 -0700
- +++ b/hello.c Sun Jun 17 18:05:50 2007 +0000
- @@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv)
- int main(int argc, char ⋆⋆argv)
+ $ hg diff
+ diff -r b57f9a090b62 hello.c
+ --- a/hello.c Tue Sep 06 15:43:07 2005 -0700
+ +++ b/hello.c Sun Jun 17 18:05:50 2007 +0000
+ @@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv)
+ int main(int argc, char ⋆⋆argv)
{
- printf("hello, world!∖");
- + printf("hello again!∖n");
- return 0;
+ printf("hello, world!∖");
+ + printf("hello again!∖n");
+ return 0;
}
### 2.7 Recording changes in a new changeset
2. If you have set the HGUSER environment variable, this is checked next.
3. If you create a file in your home directory called .hgrc, with a
username entry, that will be used next. To see what the contents
- of this file should look like, refer to section [2.7.1][11]
+ of this file should look like, refer to section [2.7.1][11]
below.
4. If you have set the EMAIL environment variable, this will be used
next.
your personalised configuration settings. The initial contents of your
.hgrc should look like this.
- # This is a Mercurial configuration file.
+ # This is a Mercurial configuration file.
[ui]
- username = Firstname Lastname <email.address@domain.net>
+ username = Firstname Lastname <email.address@domain.net>
The “[ui]” line begins a section of the config file, so you can read
the “username = ...” line as meaning “set the value of the username
for readers of what we did and why, and it will be printed by “hg log”
after we’ve finished committing.
- $ hg commit
+ $ hg commit
The editor that the “hg commit” command drops us into will contain an
empty line, followed by a number of lines starting with “HG:”.
- empty line
- HG: changed hello.c
+ empty line
+ HG: changed hello.c
Mercurial ignores the lines that start with “HG:”; it uses them only
to tell us which files it’s recording changes to. Modifying or
alone. Here’s a real example of a commit message that doesn’t follow
this guideline, and hence has a summary that is not readable.
- changeset: 73:584af0e231be
- user: Censored Person <censored.person@example.org>
- date: Tue Sep 26 21:37:07 2006 -0700
- summary: include buildmeister/commondefs. Add an exports and install
+ changeset: 73:584af0e231be
+ user: Censored Person <censored.person@example.org>
+ date: Tue Sep 26 21:37:07 2006 -0700
+ summary: include buildmeister/commondefs. Add an exports and install
As far as the remainder of the contents of the commit message are
concerned, there are no hard-and-fast rules. Mercurial itself doesn’t
that is identical to “hg log”, but it only displays the newest
revision in the repository.
- $ hg tip -vp
- changeset: 5:fa1321bf0c80
- tag: tip
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- files: hello.c
+ $ hg tip -vp
+ changeset: 5:fa1321bf0c80
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sun Jun 17 18:05:50 2007 +0000
+ files: hello.c
description:
- Added an extra line of output
+ Added an extra line of output
- diff -r b57f9a090b62 -r fa1321bf0c80 hello.c
- --- a/hello.c Tue Sep 06 15:43:07 2005 -0700
- +++ b/hello.c Sun Jun 17 18:05:50 2007 +0000
- @@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv)
- int main(int argc, char ⋆⋆argv)
+ diff -r b57f9a090b62 -r fa1321bf0c80 hello.c
+ --- a/hello.c Tue Sep 06 15:43:07 2005 -0700
+ +++ b/hello.c Sun Jun 17 18:05:50 2007 +0000
+ @@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv)
+ int main(int argc, char ⋆⋆argv)
{
- printf("hello, world!∖");
- + printf("hello again!∖n");
- return 0;
+ printf("hello, world!∖");
+ + printf("hello again!∖n");
+ return 0;
}
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
+ $ 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
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 <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ cd hello-pull
+ $ hg incoming ../my-hello
+ comparing with ../my-hello
+ searching for changes
+ changeset: 5:fa1321bf0c80
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ 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
Bringing changes into a repository is a simple matter of running the
“hg pull” command, and telling it which repository to pull from.
- $ hg tip
- changeset: 4:b57f9a090b62
- tag: tip
- user: Bryan O'Sullivan <bos@serpentine.com>
- date: Tue Sep 06 15:43:07 2005 -0700
- summary: Trim comments.
+ $ hg tip
+ changeset: 4:b57f9a090b62
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ 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 <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ 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 <bos@serpentine.com>
+ date: Sun Jun 17 18:05:50 2007 +0000
+ summary: Added an extra line of output
As you can see from the before-and-after output of “hg tip”, we have
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
+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");
+ $ 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
Mercurial lets you combine the two by passing the -u option to “hg
pull”.
- hg pull -u
+ hg pull -u
-If you look back at the output of “hg pull” in section [2.8.1][12]
+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)
+ (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 <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ hg parents
+ changeset: 5:fa1321bf0c80
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ 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
+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 <bos@serpentine.com>
- date: Tue Sep 06 13:15:43 2005 -0700
- summary: Introduce a typo into hello.c.
+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 <bos@serpentine.com>
+ 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
+ $ 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
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
+ $ 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 <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ cd my-hello
+ $ hg outgoing ../hello-push
+ comparing with ../hello-push
+ searching for changes
+ changeset: 5:fa1321bf0c80
+ tag: tip
+ user: Bryan O'Sullivan <bos@serpentine.com>
+ date: Sun Jun 17 18:05:50 2007 +0000
+ summary: Added an extra line of output
And the “hg push” command does the actual push.
- $ 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
+ $ 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
As with “hg pull”, the “hg push” command does not update the working
directory in the repository that it’s pushing changes into. (Unlike
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
+ $ hg push ../hello-push
+ pushing to ../hello-push
+ searching for changes
+ no changes found
#### 2.8.4 Sharing changes over a network
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 <bos@serpentine.com>
- date: Sun Jun 17 18:05:50 2007 +0000
- summary: Added an extra line of output
+ $ 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 <bos@serpentine.com>
+ date: Sun Jun 17 18:05:50 2007 +0000
+ summary: Added an extra line of output
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
+ $ 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
[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
[http://www.opencontent.org/openpub/][http://www.opencontent.org/openpub/]).
The reference must be immediately followed with any options elected by
-the author(s) and/or publisher of the document (see section D.6).
+the author(s) and/or publisher of the document (see section D.6).
Commercial redistribution of Open Publication-licensed material is
permitted.
projects / hgbook-git / commitdiff