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
+first line of each commit message will be shown. 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.
complete commit identifier, (perhaps in bug-tracking systems to
indicate a specific commit that fixes a bug, for example). But often,
in more casual settings, it's more convenient to use abbreviated
-commit identifiers. Git accept any unique prefix of a commit
-identifier, (and for reasonably-sized project the first 8 or 10
+commit identifiers. Git accepts any unique prefix of a commit
+identifier, (and for reasonably-sized projects the first 8 or 10
characters are almost always unique).
And unlike the permanent commit identifiers, git also provides
Or perhaps you'd like to see the actual patch content of each change,
which you can get with -p. That commit with the word typo in its name
-looks suspicous, so let's tak a closer look. Remember that we can name
+looks suspicious, so let's take a closer look. Remember that we can name
it as master~3, HEAD~3, or any prefix of its commit identifier, (such
as 13ed136b):
#### 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
+summarizes the commit, a blank line, and then one or more paragraphs
with supporting detail. Since many tools only print the first line of
a commit message by default, it’s important that the first line stands
alone.
the output of "git log --stat" or “git log -p", (so repeating the list
of all modified files is not useful, for example).
+To follow along with the example here, go ahead and type something
+like the following sentence into the editor. The misspelling here is
+intentional. You'll see how to fix that up after the fact in just a
+moment:
+
+ Fixed the typo so the program actuall complies now.
+
+Then save the file, and exit from the editor. When you do that, git
+will create the commit.
+
#### 2.7.4 Aborting a commit
If you decide that you don’t want to commit while in the middle of
So now that we've cloned a local repository, made a change to the
code, setup our name and email address, and made a careful commit,
we're just about ready to share our change with the world. But wait,
-that commit message has some really embarrassing misspellings in
-it. Wouldn't it be nice to touch those up before I post this commit
+that commit message has that embarrassing misspelling in
+it. Wouldn't it be nice to touch that up before we post this commit
with a never-to-be-changed again commit identifier?
This is the exact situation for which "git commit --amend" was
-invented. So I can just run that now and fix the broken commit
-message:
+invented. So you can just run that now and fix the broken commit
+message in the editor:
$ git commit --amend
One advantage of using git over some other systems is that the commit
speed is blazingly fast. The tool doesn't punish you at all for
-committing as often as you get our project into a state that is worth
-saving. "Commit early, commit often" is a well-supported mode of
-operation with git.
+committing every time your project is in a state worth saving. "Commit
+early, commit often" is a well-supported mode of operation with git.
### 2.8 Sharing changes
the progress-tracking spew were reduced to a single line. Something
like "Computing (100%) Transferring (100%)" or whatever.
-After (lots!) of progresss indication, git gives a report of which
+After (lots!) of progress indication, git gives a report of which
files were modified, (which is very useful for getting a quick feel
for what happened). If you would like more details on what changes
came in, git provides a range that is perfect for examining. Let's
Sometimes you may not know if you want to pull in the changes from the
remote repository or not. It's useful to be able to examine them
before accepting them into our branch. The "git pull" command shown in
-the previous section is conceptually the combination of two command,
+the previous section is conceptually the combination of two commands,
"git fetch" and "git merge". We can use these commands separately to
examine the change before accepting it.
These remote-tracking branches make it very easy to collaborate with
people as they are working on experimental features not yet ready for
upstream inclusion. For example, if fred's latest code is still
-trashing filesystems then he might not want to push it out the the
+trashing filesystems then he might not want to push it out to the
project's primary repository. But he may still want my help with
it. So he can push it to a branch in his own repository for which I've
got a remote. Then on my next "git fetch fred" I might notice a new
projects / hgbook-git / blobdiff