6127c08647 · matheusbsbs/matheus-bagliano

@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they

188 did, and why.

189

190 Every commit has a 40-hexdigit id, sometimes called the "object name" or the

191 -"SHA1 id", shown on the first line of the "git-show" output. You can usually

191 +"SHA1 id", shown on the first line of the "git show" output. You can usually

192 refer to a commit by a shorter name, such as a tag or a branch name, but this

193 longer name can also be useful. Most importantly, it is a globally unique

194 name for this commit: so if you tell somebody else the object name (for

@@ -307,7 +307,7 @@ ref: refs/heads/master

307 Examining an old version without creating a new branch

308 ------------------------------------------------------

309

310 -The git-checkout command normally expects a branch head, but will also

310 +The `git checkout` command normally expects a branch head, but will also

311 accept an arbitrary commit; for example, you can check out the commit

312 referenced by a tag:

313

@@ -400,7 +400,7 @@ references with the same shorthand name, see the "SPECIFYING

400 REVISIONS" section of linkgit:git-rev-parse[1].

401

402 [[Updating-a-repository-With-git-fetch]]

403 -Updating a repository with git-fetch

403 +Updating a repository with git fetch

404 ------------------------------------

405

406 Eventually the developer cloned from will do additional work in her

@@ -427,7 +427,7 @@ $ git fetch linux-nfs

427 -------------------------------------------------

428

429 New remote-tracking branches will be stored under the shorthand name

430 -that you gave "git-remote add", in this case linux-nfs:

430 +that you gave "git remote add", in this case linux-nfs:

431

432 -------------------------------------------------

433 $ git branch -r

@@ -516,7 +516,7 @@ $ git bisect reset

516

517 to return you to the branch you were on before.

518

519 -Note that the version which git-bisect checks out for you at each

519 +Note that the version which `git bisect` checks out for you at each

520 point is just a suggestion, and you're free to try a different

521 version if you think it would be a good idea. For example,

522 occasionally you may land on a commit that broke something unrelated;

@@ -592,11 +592,11 @@ In addition to HEAD, there are several other special names for

592 commits:

593

594 Merges (to be discussed later), as well as operations such as

595 -git-reset, which change the currently checked-out commit, generally

595 +`git reset`, which change the currently checked-out commit, generally

596 set ORIG_HEAD to the value HEAD had before the current operation.

597

598 -The git-fetch operation always stores the head of the last fetched

599 -branch in FETCH_HEAD. For example, if you run git fetch without

598 +The `git fetch` operation always stores the head of the last fetched

599 +branch in FETCH_HEAD. For example, if you run `git fetch` without

600 specifying a local branch as the target of the operation

601

602 -------------------------------------------------

@@ -1073,9 +1073,9 @@ $ git diff

1073

1074 shows the difference between the working tree and the index file.

1075

1076 -Note that "git-add" always adds just the current contents of a file

1076 +Note that "git add" always adds just the current contents of a file

1077 to the index; further changes to the same file will be ignored unless

1078 -you run git-add on the file again.

1078 +you run `git add` on the file again.

1079

1080 When you're ready, just run

1081

@@ -1136,7 +1136,7 @@ Ignoring files

1136 A project will often generate files that you do 'not' want to track with git.

1137 This typically includes files generated by a build process or temporary

1138 backup files made by your editor. Of course, 'not' tracking files with git

1139 -is just a matter of 'not' calling `git-add` on them. But it quickly becomes

1139 +is just a matter of 'not' calling `git add` on them. But it quickly becomes

1140 annoying to have these untracked files lying around; e.g. they make

1141 `git add .` practically useless, and they keep showing up in the output of

1142 `git status`.

@@ -1349,7 +1349,7 @@ $ git add file.txt

1349 -------------------------------------------------

1350

1351 the different stages of that file will be "collapsed", after which

1352 -git-diff will (by default) no longer show diffs for that file.

1352 +`git diff` will (by default) no longer show diffs for that file.

1353

1354 [[undoing-a-merge]]

1355 Undoing a merge

@@ -1446,7 +1446,7 @@ Fixing a mistake by rewriting history

1446

1447 If the problematic commit is the most recent commit, and you have not

1448 yet made that commit public, then you may just

1449 -<<undoing-a-merge,destroy it using git-reset>>.

1449 +<<undoing-a-merge,destroy it using `git reset`>>.

1450

1451 Alternatively, you

1452 can edit the working directory and update the index to fix your

@@ -1474,7 +1474,7 @@ Checking out an old version of a file

1474

1475 In the process of undoing a previous bad change, you may find it

1476 useful to check out an older version of a particular file using

1477 -linkgit:git-checkout[1]. We've used git-checkout before to switch

1477 +linkgit:git-checkout[1]. We've used `git checkout` before to switch

1478 branches, but it has quite different behavior if it is given a path

1479 name: the command

1480

@@ -1542,7 +1542,7 @@ $ git gc

1542 -------------------------------------------------

1543

1544 to recompress the archive. This can be very time-consuming, so

1545 -you may prefer to run git-gc when you are not doing other work.

1545 +you may prefer to run `git gc` when you are not doing other work.

1546

1547

1548 [[ensuring-reliability]]

@@ -1634,7 +1634,7 @@ In some situations the reflog may not be able to save you. For example,

1634 suppose you delete a branch, then realize you need the history it

1635 contained. The reflog is also deleted; however, if you have not yet

1636 pruned the repository, then you may still be able to find the lost

1637 -commits in the dangling objects that git-fsck reports. See

1637 +commits in the dangling objects that `git fsck` reports. See

1638 <<dangling-objects>> for the details.

1639

1640 -------------------------------------------------

@@ -1676,7 +1676,7 @@ Sharing development with others

1676 ===============================

1677

1678 [[getting-updates-With-git-pull]]

1679 -Getting updates with git-pull

1679 +Getting updates with git pull

1680 -----------------------------

1681

1682 After you clone a repository and make a few changes of your own, you

@@ -1722,7 +1722,7 @@ repository that you pulled from.

1722 <<fast-forwards,fast forward>>; instead, your branch will just be

1723 updated to point to the latest commit from the upstream branch.)

1724

1725 -The git-pull command can also be given "." as the "remote" repository,

1725 +The `git pull` command can also be given "." as the "remote" repository,

1726 in which case it just merges in a branch from the current repository; so

1727 the commands

1728

@@ -1795,7 +1795,7 @@ Public git repositories

1795 Another way to submit changes to a project is to tell the maintainer

1796 of that project to pull the changes from your repository using

1797 linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull,

1798 -Getting updates with git-pull>>" we described this as a way to get

1798 +Getting updates with `git pull`>>" we described this as a way to get

1799 updates from the "main" repository, but it works just as well in the

1800 other direction.

1801

@@ -1847,7 +1847,7 @@ Setting up a public repository

1847 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1848

1849 Assume your personal repository is in the directory ~/proj. We

1850 -first create a new clone of the repository and tell git-daemon that it

1850 +first create a new clone of the repository and tell `git daemon` that it

1851 is meant to be public:

1852

1853 -------------------------------------------------

@@ -1878,10 +1878,10 @@ repository>>", below.

1878 Otherwise, all you need to do is start linkgit:git-daemon[1]; it will

1879 listen on port 9418. By default, it will allow access to any directory

1880 that looks like a git directory and contains the magic file

1881 -git-daemon-export-ok. Passing some directory paths as git-daemon

1881 +git-daemon-export-ok. Passing some directory paths as `git daemon`

1882 arguments will further restrict the exports to those paths.

1883

1884 -You can also run git-daemon as an inetd service; see the

1884 +You can also run `git daemon` as an inetd service; see the

1885 linkgit:git-daemon[1] man page for details. (See especially the

1886 examples section.)

1887

@@ -1942,7 +1942,7 @@ or just

1942 $ git push ssh://yourserver.com/~you/proj.git master

1943 -------------------------------------------------

1944

1945 -As with git-fetch, git-push will complain if this does not result in a

1945 +As with `git fetch`, `git push` will complain if this does not result in a

1946 <<fast-forwards,fast forward>>; see the following section for details on

1947 handling this case.

1948

@@ -1952,7 +1952,7 @@ repository that has a checked-out working tree, but the working tree

1952 will not be updated by the push. This may lead to unexpected results if

1953 the branch you push to is the currently checked-out branch!

1954

1955 -As with git-fetch, you may also set up configuration options to

1955 +As with `git fetch`, you may also set up configuration options to

1956 save typing; so, for example, after

1957

1958 -------------------------------------------------

@@ -1988,13 +1988,13 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'

1988

1989 This can happen, for example, if you:

1990

1991 - - use `git-reset --hard` to remove already-published commits, or

1992 - - use `git-commit --amend` to replace already-published commits

1991 + - use `git reset --hard` to remove already-published commits, or

1992 + - use `git commit --amend` to replace already-published commits

1993 (as in <<fixing-a-mistake-by-rewriting-history>>), or

1994 - - use `git-rebase` to rebase any already-published commits (as

1994 + - use `git rebase` to rebase any already-published commits (as

1995 in <<using-git-rebase>>).

1996

1997 -You may force git-push to perform the update anyway by preceding the

1997 +You may force `git push` to perform the update anyway by preceding the

1998 branch name with a plus sign:

1999

2000 -------------------------------------------------

@@ -2036,7 +2036,7 @@ advantages over the central shared repository:

2036

2037 - Git's ability to quickly import and merge patches allows a

2038 single maintainer to process incoming changes even at very

2039 - high rates. And when that becomes too much, git-pull provides

2039 + high rates. And when that becomes too much, `git pull` provides

2040 an easy way for that maintainer to delegate this job to other

2041 maintainers while still allowing optional review of incoming

2042 changes.

@@ -2404,7 +2404,7 @@ use them, and then explain some of the problems that can arise because

2404 you are rewriting history.

2405

2406 [[using-git-rebase]]

2407 -Keeping a patch series up to date using git-rebase

2407 +Keeping a patch series up to date using git rebase

2408 --------------------------------------------------

2409

2410 Suppose that you create a branch "mywork" on a remote-tracking branch

@@ -2468,9 +2468,9 @@ patches to the new mywork. The result will look like:

2468 ................................................

2469

2470 In the process, it may discover conflicts. In that case it will stop

2471 -and allow you to fix the conflicts; after fixing conflicts, use "git-add"

2471 +and allow you to fix the conflicts; after fixing conflicts, use `git add`

2472 to update the index with those contents, and then, instead of

2473 -running git-commit, just run

2473 +running `git commit`, just run

2474

2475 -------------------------------------------------

2476 $ git rebase --continue

@@ -2508,7 +2508,7 @@ with

2508 $ git tag bad mywork~5

2509 -------------------------------------------------

2510

2511 -(Either gitk or git-log may be useful for finding the commit.)

2511 +(Either gitk or `git log` may be useful for finding the commit.)

2512

2513 Then check out that commit, edit it, and rebase the rest of the series

2514 on top of it (note that we could check out the commit on a temporary

@@ -2549,12 +2549,12 @@ $ gitk origin..mywork &

2549

2550 and browse through the list of patches in the mywork branch using gitk,

2551 applying them (possibly in a different order) to mywork-new using

2552 -cherry-pick, and possibly modifying them as you go using `commit --amend`.

2552 +cherry-pick, and possibly modifying them as you go using `git commit --amend`.

2553 The linkgit:git-gui[1] command may also help as it allows you to

2554 individually select diff hunks for inclusion in the index (by

2555 right-clicking on the diff hunk and choosing "Stage Hunk for Commit").

2556

2557 -Another technique is to use git-format-patch to create a series of

2557 +Another technique is to use `git format-patch` to create a series of

2558 patches, then reset the state to before the patches:

2559

2560 -------------------------------------------------

@@ -2662,7 +2662,7 @@ you know is that D is bad, that Z is good, and that

2662 linkgit:git-bisect[1] identifies C as the culprit, how will you

2663 figure out that the problem is due to this change in semantics?

2664

2665 -When the result of a git-bisect is a non-merge commit, you should

2665 +When the result of a `git bisect` is a non-merge commit, you should

2666 normally be able to discover the problem by examining just that commit.

2667 Developers can make this easy by breaking their changes into small

2668 self-contained commits. That won't help in the case above, however,

@@ -2725,7 +2725,7 @@ master branch. In more detail:

2725 git fetch and fast-forwards

2726 ---------------------------

2727

2728 -In the previous example, when updating an existing branch, "git-fetch"

2728 +In the previous example, when updating an existing branch, "git fetch"

2729 checks to make sure that the most recent commit on the remote

2730 branch is a descendant of the most recent commit on your copy of the

2731 branch before updating your copy of the branch to point at the new

@@ -2751,7 +2751,7 @@ resulting in a situation like:

2751 o--o--o <-- new head of the branch

2752 ................................................

2753

2754 -In this case, "git-fetch" will fail, and print out a warning.

2754 +In this case, "git fetch" will fail, and print out a warning.

2755

2756 In that case, you can still force git to update to the new head, as

2757 described in the following section. However, note that in the

@@ -2760,7 +2760,7 @@ unless you've already created a reference of your own pointing to

2760 them.

2761

2762 [[forcing-fetch]]

2763 -Forcing git-fetch to do non-fast-forward updates

2763 +Forcing git fetch to do non-fast-forward updates

2764 ------------------------------------------------

2765

2766 If git fetch fails because the new head of a branch is not a

@@ -3131,7 +3131,7 @@ $ git prune

3131

3132 to remove any of the "loose" objects that are now contained in the

3133 pack. This will also remove any unreferenced objects (which may be

3134 -created when, for example, you use "git-reset" to remove a commit).

3134 +created when, for example, you use "git reset" to remove a commit).

3135 You can verify that the loose objects are gone by looking at the

3136 .git/objects directory or by running

3137

@@ -3160,7 +3160,7 @@ branch still exists, as does everything it pointed to. The branch

3160 pointer itself just doesn't, since you replaced it with another one.

3161

3162 There are also other situations that cause dangling objects. For

3163 -example, a "dangling blob" may arise because you did a "git-add" of a

3163 +example, a "dangling blob" may arise because you did a "git add" of a

3164 file, but then, before you actually committed it and made it part of the

3165 bigger picture, you changed something else in that file and committed

3166 that *updated* thing--the old state that you added originally ends up

@@ -3210,7 +3210,7 @@ Usually, dangling blobs and trees aren't very interesting. They're

3210 almost always the result of either being a half-way mergebase (the blob

3211 will often even have the conflict markers from a merge in it, if you

3212 have had conflicting merges that you fixed up by hand), or simply

3213 -because you interrupted a "git-fetch" with ^C or something like that,

3213 +because you interrupted a "git fetch" with ^C or something like that,

3214 leaving _some_ of the new objects in the object database, but just

3215 dangling and useless.

3216

@@ -3225,9 +3225,9 @@ and they'll be gone. But you should only run "git prune" on a quiescent

3225 repository--it's kind of like doing a filesystem fsck recovery: you

3226 don't want to do that while the filesystem is mounted.

3227

3228 -(The same is true of "git-fsck" itself, btw, but since

3229 -git-fsck never actually *changes* the repository, it just reports

3230 -on what it found, git-fsck itself is never "dangerous" to run.

3228 +(The same is true of "git fsck" itself, btw, but since

3229 +`git fsck` never actually *changes* the repository, it just reports

3230 +on what it found, `git fsck` itself is never 'dangerous' to run.

3231 Running it while somebody is actually changing the repository can cause

3232 confusing and scary messages, but it won't actually do anything bad. In

3233 contrast, running "git prune" while somebody is actively changing the

@@ -3489,14 +3489,14 @@ done

3489

3490 NOTE: Do not use local URLs here if you plan to publish your superproject!

3491

3492 -See what files `git-submodule` created:

3492 +See what files `git submodule` created:

3493

3494 -------------------------------------------------

3495 $ ls -a

3496 . .. .git .gitmodules a b c d

3497 -------------------------------------------------

3498

3499 -The `git-submodule add <repo> <path>` command does a couple of things:

3499 +The `git submodule add <repo> <path>` command does a couple of things:

3500

3501 - It clones the submodule from <repo> to the given <path> under the

3502 current directory and by default checks out the master branch.

@@ -3542,7 +3542,7 @@ init` to add the submodule repository URLs to `.git/config`:

3542 $ git submodule init

3543 -------------------------------------------------

3544

3545 -Now use `git-submodule update` to clone the repositories and check out the

3545 +Now use `git submodule update` to clone the repositories and check out the

3546 commits specified in the superproject:

3547

3548 -------------------------------------------------

@@ -3552,8 +3552,8 @@ $ ls -a

3552 . .. .git a.txt

3553 -------------------------------------------------

3554

3555 -One major difference between `git-submodule update` and `git-submodule add` is

3556 -that `git-submodule update` checks out a specific commit, rather than the tip

3555 +One major difference between `git submodule update` and `git submodule add` is

3556 +that `git submodule update` checks out a specific commit, rather than the tip

3557 of a branch. It's like checking out a tag: the head is detached, so you're not

3558 working on a branch.

3559

@@ -3769,7 +3769,7 @@ You update your working directory from the index by "checking out"

3769 files. This is not a very common operation, since normally you'd just

3770 keep your files updated, and rather than write to your working

3771 directory, you'd tell the index files about the changes in your

3772 -working directory (i.e. `git-update-index`).

3772 +working directory (i.e. `git update-index`).

3773

3774 However, if you decide to jump to a new version, or check out somebody

3775 else's version, or just restore a previous tree, you'd populate your

@@ -3782,7 +3782,7 @@ $ git checkout-index filename

3782

3783 or, if you want to check out all of the index, use `-a`.

3784

3785 -NOTE! git-checkout-index normally refuses to overwrite old files, so

3785 +NOTE! `git checkout-index` normally refuses to overwrite old files, so

3786 if you have an old version of the tree already checked out, you will

3787 need to use the "-f" flag ('before' the "-a" flag or the filename) to

3788 'force' the checkout.

@@ -3820,7 +3820,7 @@ $ git commit-tree <tree> -p <parent> [-p <parent2> ..]

3820 and then giving the reason for the commit on stdin (either through

3821 redirection from a pipe or file, or by just typing it at the tty).

3822

3823 -git-commit-tree will return the name of the object that represents

3823 +`git commit-tree` will return the name of the object that represents

3824 that commit, and you should save it away for later use. Normally,

3825 you'd commit a new `HEAD` state, and while git doesn't care where you

3826 save the note about that state, in practice we tend to just write the

@@ -3889,7 +3889,7 @@ $ git cat-file blob|tree|commit|tag <objectname>

3889

3890 to show its contents. NOTE! Trees have binary content, and as a result

3891 there is a special helper for showing that content, called

3892 -`git-ls-tree`, which turns the binary content into a more easily

3892 +`git ls-tree`, which turns the binary content into a more easily

3893 readable form.

3894

3895 It's especially instructive to look at "commit" objects, since those

@@ -3984,7 +3984,7 @@ came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`

3984 tree, and stage3 `$target` tree.

3985

3986 Earlier we said that trivial merges are done inside

3987 -`git-read-tree -m`. For example, if the file did not change

3987 +`git read-tree -m`. For example, if the file did not change

3988 from `$orig` to `HEAD` nor `$target`, or if the file changed

3989 from `$orig` to `HEAD` and `$orig` to `$target` the same way,

3990 obviously the final outcome is what is in `HEAD`. What the

@@ -4011,20 +4011,20 @@ $ mv -f hello.c~2 hello.c

4011 $ git update-index hello.c

4012 -------------------------------------------------

4013

4014 -When a path is in the "unmerged" state, running `git-update-index` for

4014 +When a path is in the "unmerged" state, running `git update-index` for

4015 that path tells git to mark the path resolved.

4016

4017 The above is the description of a git merge at the lowest level,

4018 to help you understand what conceptually happens under the hood.

4019 -In practice, nobody, not even git itself, runs `git-cat-file` three times

4020 -for this. There is a `git-merge-index` program that extracts the

4019 +In practice, nobody, not even git itself, runs `git cat-file` three times

4020 +for this. There is a `git merge-index` program that extracts the

4021 stages to temporary files and calls a "merge" script on it:

4022

4023 -------------------------------------------------

4024 $ git merge-index git-merge-one-file hello.c

4025 -------------------------------------------------

4026

4027 -and that is what higher level `git-merge -s resolve` is implemented with.

4027 +and that is what higher level `git merge -s resolve` is implemented with.

4028

4029 [[hacking-git]]

4030 Hacking git

@@ -4061,7 +4061,7 @@ size> {plus} <byte\0> {plus} <binary object data>.

4061

4062 The structured objects can further have their structure and

4063 connectivity to other objects verified. This is generally done with

4064 -the `git-fsck` program, which generates a full dependency graph

4064 +the `git fsck` program, which generates a full dependency graph

4065 of all objects, and verifies their internal consistency (in addition

4066 to just verifying their superficial consistency through the hash).

4067

@@ -4120,7 +4120,7 @@ functions like `get_sha1_basic()` or the likes.

4120 This is just to get you into the groove for the most libified part of Git:

4121 the revision walker.

4122

4123 -Basically, the initial version of `git-log` was a shell script:

4123 +Basically, the initial version of `git log` was a shell script:

4124

4125 ----------------------------------------------------------------

4126 $ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \

@@ -4129,20 +4129,20 @@ $ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \

4129

4130 What does this mean?

4131

4132 -`git-rev-list` is the original version of the revision walker, which

4132 +`git rev-list` is the original version of the revision walker, which

4133 _always_ printed a list of revisions to stdout. It is still functional,

4134 and needs to, since most new Git programs start out as scripts using

4135 -`git-rev-list`.

4135 +`git rev-list`.

4136

4137 -`git-rev-parse` is not as important any more; it was only used to filter out

4137 +`git rev-parse` is not as important any more; it was only used to filter out

4138 options that were relevant for the different plumbing commands that were

4139 called by the script.

4140

4141 -Most of what `git-rev-list` did is contained in `revision.c` and

4141 +Most of what `git rev-list` did is contained in `revision.c` and

4142 `revision.h`. It wraps the options in a struct named `rev_info`, which

4143 controls how and what revisions are walked, and more.

4144

4145 -The original job of `git-rev-parse` is now taken by the function

4145 +The original job of `git rev-parse` is now taken by the function

4146 `setup_revisions()`, which parses the revisions and the common command line

4147 options for the revision walker. This information is stored in the struct

4148 `rev_info` for later consumption. You can do your own command line option

@@ -4155,7 +4155,7 @@ just have a look at the first implementation of `cmd_log()`; call

4155 `git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you

4156 no longer need to call `setup_pager()` directly).

4157

4158 -Nowadays, `git-log` is a builtin, which means that it is _contained_ in the

4158 +Nowadays, `git log` is a builtin, which means that it is _contained_ in the

4159 command `git`. The source side of a builtin is

4160

4161 - a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,

@@ -4171,7 +4171,7 @@ since they share quite a bit of code. In that case, the commands which are

4171 _not_ named like the `.c` file in which they live have to be listed in

4172 `BUILT_INS` in the `Makefile`.

4173

4174 -`git-log` looks more complicated in C than it does in the original script,

4174 +`git log` looks more complicated in C than it does in the original script,

4175 but that allows for a much greater flexibility and performance.

4176

4177 Here again it is a good point to take a pause.

@@ -4182,9 +4182,9 @@ the organization of Git (after you know the basic concepts).

4182 So, think about something which you are interested in, say, "how can I

4183 access a blob just knowing the object name of it?". The first step is to

4184 find a Git command with which you can do it. In this example, it is either

4185 -`git-show` or `git-cat-file`.

4185 +`git show` or `git cat-file`.

4186

4187 -For the sake of clarity, let's stay with `git-cat-file`, because it

4187 +For the sake of clarity, let's stay with `git cat-file`, because it

4188

4189 - is plumbing, and

4190

@@ -4198,7 +4198,7 @@ it does.

4198 ------------------------------------------------------------------

4199 git_config(git_default_config);

4200 if (argc != 3)

4201 - usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");

4201 + usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>");

4202 if (get_sha1(argv[2], sha1))

4203 die("Not a valid object name %s", argv[2]);

4204 ------------------------------------------------------------------

@@ -4243,10 +4243,10 @@ To find out how the result can be used, just read on in `cmd_cat_file()`:

4243 -----------------------------------

4244

4245 Sometimes, you do not know where to look for a feature. In many such cases,

4246 -it helps to search through the output of `git log`, and then `git-show` the

4246 +it helps to search through the output of `git log`, and then `git show` the

4247 corresponding commit.

4248

4249 -Example: If you know that there was some test case for `git-bundle`, but

4249 +Example: If you know that there was some test case for `git bundle`, but

4250 do not remember where it was (yes, you _could_ `git grep bundle t/`, but that

4251 does not illustrate the point!):

4252

@@ -4530,7 +4530,7 @@ The basic requirements:

4530 - Whenever possible, section headings should clearly describe the task

4531 they explain how to do, in language that requires no more knowledge

4532 than necessary: for example, "importing patches into a project" rather

4533 - than "the git-am command"

4533 + than "the `git am` command"

4534

4535 Think about how to create a clear chapter dependency graph that will

4536 allow people to get to important topics without necessarily reading

user-manual: remove some git-foo usage