X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=tour.mdwn;h=1ac764eeb58a81a2cfcef60319ed09fbf4baca18;hb=28d905b55e34369acb3686f909b7ccbf6a8035ea;hp=2d209d76c130042d61ac181bcc65f4f34e725e25;hpb=8c03a7b3485bd7dda6913a02db01b8e70a6d768a;p=hgbook-git diff --git a/tour.mdwn b/tour.mdwn index 2d209d7..1ac764e 100644 --- a/tour.mdwn +++ b/tour.mdwn @@ -120,9 +120,9 @@ times when you find yourself stuck trying to remember how to run a command. If you are completely stuck, simply run “git help”; it will print a brief list of commonly-used commands, along with a description of what each does. If you ask for help on a specific command (such as -"git help init"), it prints more detailed information. [XXX: Does "git -help \" work universally as a built-in or does it expect man to be -present and just call out to "man git-\"?] +"git help init"), it prints more detailed information. [XXX: Does `git +help ` work universally as a built-in or does it expect man to be +present and just call out to `man git-`?] [XXX: The original hgbook includes the complete output of "hg help init" at this point. I'm not including the corresponding @@ -292,21 +292,21 @@ view of history. Create a standard "hello, world" program -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. +This command prints a record 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 default 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. * Author The identity of the person who authored the commit. This field consist of two sub-fields for the user's name and email address, (or at least an email-like idenitifer). Note that git - stores a separate "Committer" field for the person who commited - the change, (since often an author will email a change to a - maintainer that commits it). The "git log" command doesn't display - the Committer, but other git tools do. + also stores a separate "Committer" field for the person who + commited the change, (since often an author will email a change to + a maintainer that commits it). See below for how to instruct "git + log" to display it as well. * Date The date and time on which the commit was authored, (again stored separately from the date the change was committed). timezone in which it was created. (The date and time are displayed @@ -315,8 +315,13 @@ The fields in a record of output from “git log” are as follows. entered to describe the commit, (generally a one-line summary followed by more supporting text). -The default output printed by “git log” is purely a summary; it is -missing a lot of detail. +The output of the "git log" command can be made more or less verbose +by means of the --pretty option. For example, with "git log +--pretty=short" the commit identifier will be omitted and only the +first line of each commit message will be show. And with "git log +--pretty=fuller", (the name 'fuller' is in contrast to the default +--pretty=full), the committer name and dates will be printed in +addition to the author name and dates. #### 2.4.1 Commits, revisions, and talking to other people @@ -525,14 +530,14 @@ conventions for options that are common to modern Linux and Unix systems. * Most options have long names. For example, as we’ve already seen, - the “git log" command accepts a --max-count=\ option. + the “git log" command accepts a `--max-count=` option. * Some options have short, single-character names. Often these are - aliases for long commands, (such as "-n \" instead of - --max-count=\), but sometimes the option exists in - short-form with no long-form equivalent, (such as -p). [XXX: It - wouldn't hurt to fix this by adding --patch, etc. right?] - * Long options start with two dashes (e.g. --max-count), while short - options start with one (e.g. -n). + aliases for long commands, (such as `-n ` instead of + `--max-count=`), but sometimes the option exists in + short-form with no long-form equivalent, (such as `-p`). [XXX: It + wouldn't hurt to fix this by adding `--patch`, etc. right?] + * Long options start with two dashes (e.g. `--max-count`), while short + options start with one (e.g. `-n`). * Option naming and usage is consistent across commands. For example, every command that lets you specify a commit identifier @@ -643,7 +648,7 @@ attempt each of the following methods, in order, (stopping for each of the author and committer name and email as soon as a value is found): 1. If you specify a --author option to the “git commit” command on - the command line, followed by a "Real Name \" + the command line, followed by a `"Real Name "` string, then this name and addresss will be used for the author fields. The committer fields will still be determined as below. This option is very helpful for when applying a commit @@ -723,7 +728,7 @@ as a comment. You can use any text you like as the value of the name and email configuration items, since this information is for reading by other people, not for interpreting by git. It is conventional to use your -actual name as well as a valid email address. But some poepl, (notably +actual name as well as a valid email address. But some people, (notably Linus Torvalds, the original author of git), actually like the default username@hostname convention that git falls back on without any additional information about an email address. There's no requirement @@ -745,19 +750,19 @@ after we’ve finished committing. 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 \" +`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 +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 +The editor that the `git commit` command drops us into will contain an empty line, followed by a number of lines starting with “#”. These -lines contain the same information as seen in "git status" before: +lines contain the same information as seen in `git status` before: empty line # Please enter the commit message for your changes. @@ -869,8 +874,8 @@ it. Wouldn't it be nice to touch those up before I post this commit with a never-to-be-changed again commit identifier? This is the exact situation for which "git commit --amend" was - -So I can just run that now and fix the broken commit message: +invented. So I can just run that now and fix the broken commit +message: $ git commit --amend @@ -1091,7 +1096,7 @@ markers in the files and instruct you to resolve the conflicts. When you are finished, you would issue a "git commit -a" to create the merge commit. -#### 2.8.3 Using "git remote" to pull changes other repositories +#### 2.8.3 Using "git remote" to pull changes from other repositories We've already described how "git pull" will pull in changes from the repository which was the origin of the clone operation. Git also