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