1249d8ad1c · matheusbsbs/matheus-bagliano

@@ -19,7 +19,7 @@ Further chapters cover more specialized topics.

19

20 Comprehensive reference documentation is available through the man

21 pages, or linkgit:git-help[1] command. For example, for the command

22 -"git clone <repo>", you can either use:

22 +`git clone <repo>`, you can either use:

23

24 ------------------------------------------------

25 $ man git-clone

@@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

66 The initial clone may be time-consuming for a large project, but you

67 will only need to clone once.

68

69 -The clone command creates a new directory named after the project ("git"

70 -or "linux-2.6" in the examples above). After you cd into this

69 +The clone command creates a new directory named after the project (`git`

70 +or `linux-2.6` in the examples above). After you cd into this

71 directory, you will see that it contains a copy of the project files,

72 called the <<def_working_tree,working tree>>, together with a special

73 -top-level directory named ".git", which contains all the information

73 +top-level directory named `.git`, which contains all the information

74 about the history of the project.

75

76 [[how-to-check-out]]

@@ -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 -"SHA-1 id", shown on the first line of the "git show" output. You can usually

191 +"SHA-1 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

@@ -268,35 +268,35 @@ Manipulating branches

268 Creating, deleting, and modifying branches is quick and easy; here's

269 a summary of the commands:

270

271 -git branch::

271 +`git branch`::

272 list all branches

273 -git branch <branch>::

274 - create a new branch named <branch>, referencing the same

273 +`git branch <branch>`::

274 + create a new branch named `<branch>`, referencing the same

275 point in history as the current branch

276 -git branch <branch> <start-point>::

277 - create a new branch named <branch>, referencing

278 - <start-point>, which may be specified any way you like,

276 +`git branch <branch> <start-point>`::

277 + create a new branch named `<branch>`, referencing

278 + `<start-point>`, which may be specified any way you like,

279 including using a branch name or a tag name

280 -git branch -d <branch>::

281 - delete the branch <branch>; if the branch you are deleting

280 +`git branch -d <branch>`::

281 + delete the branch `<branch>`; if the branch you are deleting

282 points to a commit which is not reachable from the current

283 branch, this command will fail with a warning.

284 -git branch -D <branch>::

284 +`git branch -D <branch>`::

285 even if the branch points to a commit not reachable

286 from the current branch, you may know that that commit

287 is still reachable from some other branch or tag. In that

288 case it is safe to use this command to force Git to delete

289 the branch.

290 -git checkout <branch>::

291 - make the current branch <branch>, updating the working

292 - directory to reflect the version referenced by <branch>

293 -git checkout -b <new> <start-point>::

294 - create a new branch <new> referencing <start-point>, and

290 +`git checkout <branch>`::

291 + make the current branch `<branch>`, updating the working

292 + directory to reflect the version referenced by `<branch>`

293 +`git checkout -b <new> <start-point>`::

294 + create a new branch `<new>` referencing `<start-point>`, and

295 check it out.

296

297 The special symbol "HEAD" can always be used to refer to the current

298 -branch. In fact, Git uses a file named "HEAD" in the .git directory to

299 -remember which branch is current:

298 +branch. In fact, Git uses a file named `HEAD` in the `.git` directory

299 +to remember which branch is current:

300

301 ------------------------------------------------

302 $ cat .git/HEAD

@@ -346,7 +346,7 @@ of the HEAD in the repository that you cloned from. That repository

346 may also have had other branches, though, and your local repository

347 keeps branches which track each of those remote branches, called

348 remote-tracking branches, which you

349 -can view using the "-r" option to linkgit:git-branch[1]:

349 +can view using the `-r` option to linkgit:git-branch[1]:

350

351 ------------------------------------------------

352 $ git branch -r

@@ -364,7 +364,7 @@ In this example, "origin" is called a remote repository, or "remote"

364 for short. The branches of this repository are called "remote

365 branches" from our point of view. The remote-tracking branches listed

366 above were created based on the remote branches at clone time and will

367 -be updated by "git fetch" (hence "git pull") and "git push". See

367 +be updated by `git fetch` (hence `git pull`) and `git push`. See

368 <<Updating-a-repository-With-git-fetch>> for details.

369

370 You might want to build on one of these remote-tracking branches

@@ -374,7 +374,7 @@ on a branch of your own, just as you would for a tag:

374 $ git checkout -b my-todo-copy origin/todo

375 ------------------------------------------------

376

377 -You can also check out "origin/todo" directly to examine it or

377 +You can also check out `origin/todo` directly to examine it or

378 write a one-off patch. See <<detached-head,detached head>>.

379

380 Note that the name "origin" is just the name that Git uses by default

@@ -386,17 +386,17 @@ Naming branches, tags, and other references

386

387 Branches, remote-tracking branches, and tags are all references to

388 commits. All references are named with a slash-separated path name

389 -starting with "refs"; the names we've been using so far are actually

389 +starting with `refs`; the names we've been using so far are actually

390 shorthand:

391

392 - - The branch "test" is short for "refs/heads/test".

393 - - The tag "v2.6.18" is short for "refs/tags/v2.6.18".

394 - - "origin/master" is short for "refs/remotes/origin/master".

392 + - The branch `test` is short for `refs/heads/test`.

393 + - The tag `v2.6.18` is short for `refs/tags/v2.6.18`.

394 + - `origin/master` is short for `refs/remotes/origin/master`.

395

396 The full name is occasionally useful if, for example, there ever

397 exists a tag and a branch with the same name.

398

399 -(Newly created refs are actually stored in the .git/refs directory,

399 +(Newly created refs are actually stored in the `.git/refs` directory,

400 under the path given by their name. However, for efficiency reasons

401 they may also be packed together in a single file; see

402 linkgit:git-pack-refs[1]).

@@ -418,7 +418,7 @@ Eventually the developer cloned from will do additional work in her

418 repository, creating new commits and advancing the branches to point

419 at the new commits.

420

421 -The command "git fetch", with no arguments, will update all of the

421 +The command `git fetch`, with no arguments, will update all of the

422 remote-tracking branches to the latest version found in her

423 repository. It will not touch any of your own branches--not even the

424 "master" branch that was created for you on clone.

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

438 -------------------------------------------------

439

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

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

441 +that you gave `git remote add`, in this case `linux-nfs`:

442

443 -------------------------------------------------

444 $ git branch -r

@@ -446,10 +446,10 @@ linux-nfs/master

446 origin/master

447 -------------------------------------------------

448

449 -If you run "git fetch <remote>" later, the remote-tracking branches for the

450 -named <remote> will be updated.

449 +If you run `git fetch <remote>` later, the remote-tracking branches

450 +for the named `<remote>` will be updated.

451

452 -If you examine the file .git/config, you will see that Git has added

452 +If you examine the file `.git/config`, you will see that Git has added

453 a new stanza:

454

455 -------------------------------------------------

@@ -462,7 +462,7 @@ $ cat .git/config

462 -------------------------------------------------

463

464 This is what causes Git to track the remote's branches; you may modify

465 -or delete these configuration options by editing .git/config with a

465 +or delete these configuration options by editing `.git/config` with a

466 text editor. (See the "CONFIGURATION FILE" section of

467 linkgit:git-config[1] for details.)

468

@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this

499 [65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

500 -------------------------------------------------

501

502 -If you run "git branch" at this point, you'll see that Git has

502 +If you run `git branch` at this point, you'll see that Git has

503 temporarily moved you in "(no branch)". HEAD is now detached from any

504 branch and points directly to a commit (with commit id 65934...) that

505 is reachable from "master" but not from v2.6.18. Compile and test it,

@@ -545,11 +545,11 @@ id, and check it out with:

545 $ git reset --hard fb47ddb2db...

546 -------------------------------------------------

547

548 -then test, run "bisect good" or "bisect bad" as appropriate, and

548 +then test, run `bisect good` or `bisect bad` as appropriate, and

549 continue.

550

551 -Instead of "git bisect visualize" and then "git reset --hard

552 -fb47ddb2db...", you might just want to tell Git that you want to skip

551 +Instead of `git bisect visualize` and then `git reset --hard

552 +fb47ddb2db...`, you might just want to tell Git that you want to skip

553 the current commit:

554

555 -------------------------------------------------

@@ -561,8 +561,8 @@ bad one between some first skipped commits and a later bad commit.

561

562 There are also ways to automate the bisecting process if you have a

563 test script that can tell a good from a bad commit. See

564 -linkgit:git-bisect[1] for more information about this and other "git

565 -bisect" features.

564 +linkgit:git-bisect[1] for more information about this and other `git

565 +bisect` features.

566

567 [[naming-commits]]

568 Naming commits

@@ -591,7 +591,7 @@ $ git show HEAD~4 # the great-great-grandparent

591 -------------------------------------------------

592

593 Recall that merge commits may have more than one parent; by default,

594 -^ and ~ follow the first parent listed in the commit, but you can

594 +`^` and `~` follow the first parent listed in the commit, but you can

595 also choose:

596

597 -------------------------------------------------

@@ -640,7 +640,7 @@ running

640 $ git tag stable-1 1b2e1d63ff

641 -------------------------------------------------

642

643 -You can use stable-1 to refer to the commit 1b2e1d63ff.

643 +You can use `stable-1` to refer to the commit 1b2e1d63ff.

644

645 This creates a "lightweight" tag. If you would also like to include a

646 comment with the tag, and possibly sign it cryptographically, then you

@@ -669,7 +669,7 @@ $ git log -S'foo()' # commits which add or remove any file data

669 -------------------------------------------------

670

671 And of course you can combine all of these; the following finds

672 -commits since v2.5 which touch the Makefile or any file under fs:

672 +commits since v2.5 which touch the `Makefile` or any file under `fs`:

673

674 -------------------------------------------------

675 $ git log v2.5.. Makefile fs/

@@ -681,7 +681,7 @@ You can also ask git log to show patches:

681 $ git log -p

682 -------------------------------------------------

683

684 -See the "--pretty" option in the linkgit:git-log[1] man page for more

684 +See the `--pretty` option in the linkgit:git-log[1] man page for more

685 display options.

686

687 Note that git log starts with the most recent commit and works

@@ -742,8 +742,8 @@ Examples

742 Counting the number of commits on a branch

743 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

744

745 -Suppose you want to know how many commits you've made on "mybranch"

746 -since it diverged from "origin":

745 +Suppose you want to know how many commits you've made on `mybranch`

746 +since it diverged from `origin`:

747

748 -------------------------------------------------

749 $ git log --pretty=oneline origin..mybranch | wc -l

@@ -780,7 +780,7 @@ $ git rev-list master

780 e05db0fd4f31dde7005f075a84f96b360d05984b

781 -------------------------------------------------

782

783 -Or you could recall that the ... operator selects all commits

783 +Or you could recall that the `...` operator selects all commits

784 contained reachable from either one reference or the other but not

785 both; so

786

@@ -880,7 +880,7 @@ Showing commits unique to a given branch

880 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

881

882 Suppose you would like to see all the commits reachable from the branch

883 -head named "master" but not from any other head in your repository.

883 +head named `master` but not from any other head in your repository.

884

885 We can list all the heads in this repository with

886 linkgit:git-show-ref[1]:

@@ -894,7 +894,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master

894 1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes

895 -------------------------------------------------

896

897 -We can get just the branch-head names, and remove "master", with

897 +We can get just the branch-head names, and remove `master`, with

898 the help of the standard utilities cut and grep:

899

900 -------------------------------------------------

@@ -939,7 +939,7 @@ is preceded by `project/`. The output file format is inferred from

939 the output file extension if possible, see linkgit:git-archive[1] for

940 details.

941

942 -Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,

942 +Versions of Git older than 1.7.7 don't know about the `tar.gz` format,

943 you'll need to use gzip explicitly:

944

945 -------------------------------------------------

@@ -1062,7 +1062,7 @@ at step 3, Git maintains a snapshot of the tree's contents in a

1062 special staging area called "the index."

1063

1064 At the beginning, the content of the index will be identical to

1065 -that of the HEAD. The command "git diff --cached", which shows

1065 +that of the HEAD. The command `git diff --cached`, which shows

1066 the difference between the HEAD and the index, should therefore

1067 produce no output at that point.

1068

@@ -1101,7 +1101,7 @@ $ git diff

1101

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

1103

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

1104 +Note that `git add` always adds just the current contents of a file

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

1106 you run `git add` on the file again.

1107

@@ -1172,8 +1172,9 @@ annoying to have these untracked files lying around; e.g. they make

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

1173 `git status`.

1174

1175 -You can tell Git to ignore certain files by creating a file called .gitignore

1176 -in the top level of your working directory, with contents such as:

1175 +You can tell Git to ignore certain files by creating a file called

1176 +`.gitignore` in the top level of your working directory, with contents

1177 +such as:

1178

1179 -------------------------------------------------

1180 # Lines starting with '#' are considered comments.

@@ -1197,10 +1198,10 @@ for other users who clone your repository.

1198

1199 If you wish the exclude patterns to affect only certain repositories

1200 (instead of every repository for a given project), you may instead put

1200 -them in a file in your repository named .git/info/exclude, or in any file

1201 -specified by the `core.excludesfile` configuration variable. Some Git

1202 -commands can also take exclude patterns directly on the command line.

1203 -See linkgit:gitignore[5] for the details.

1201 +them in a file in your repository named `.git/info/exclude`, or in any

1202 +file specified by the `core.excludesfile` configuration variable.

1203 +Some Git commands can also take exclude patterns directly on the

1204 +command line. See linkgit:gitignore[5] for the details.

1205

1206 [[how-to-merge]]

1207 How to merge

@@ -1213,10 +1214,10 @@ linkgit:git-merge[1]:

1214 $ git merge branchname

1215 -------------------------------------------------

1216

1216 -merges the development in the branch "branchname" into the current

1217 +merges the development in the branch `branchname` into the current

1218 branch.

1219

1219 -A merge is made by combining the changes made in "branchname" and the

1220 +A merge is made by combining the changes made in `branchname` and the

1221 changes made up to the latest commit in your current branch since

1222 their histories forked. The work tree is overwritten by the result of

1223 the merge when this combining is done cleanly, or overwritten by a

@@ -1338,7 +1339,7 @@ that part is not conflicting and is not shown. Same for stage 3).

1339

1340 The diff above shows the differences between the working-tree version of

1341 file.txt and the stage 2 and stage 3 versions. So instead of preceding

1341 -each line by a single "+" or "-", it now uses two columns: the first

1342 +each line by a single `+` or `-`, it now uses two columns: the first

1343 column is used for differences between the first parent and the working

1344 directory copy, and the second for differences between the second parent

1345 and the working directory copy. (See the "COMBINED DIFF FORMAT" section

@@ -1613,7 +1614,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f

1614

1615 You will see informational messages on dangling objects. They are objects

1616 that still exist in the repository but are no longer referenced by any of

1616 -your branches, and can (and will) be removed after a while with "gc".

1617 +your branches, and can (and will) be removed after a while with `gc`.

1618 You can run `git fsck --no-dangling` to suppress these messages, and still

1619 view real errors.

1620

@@ -1625,9 +1626,9 @@ Recovering lost changes

1626 Reflogs

1627 ^^^^^^^

1628

1628 -Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then

1629 -realize that the branch was the only reference you had to that point in

1630 -history.

1629 +Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,

1630 +and then realize that the branch was the only reference you had to

1631 +that point in history.

1632

1633 Fortunately, Git also keeps a log, called a "reflog", of all the

1634 previous values of each branch. So in this case you can still find the

@@ -1638,8 +1639,8 @@ $ git log master@{1}

1639 -------------------------------------------------

1640

1641 This lists the commits reachable from the previous version of the

1641 -"master" branch head. This syntax can be used with any Git command

1642 -that accepts a commit, not just with git log. Some other examples:

1642 +`master` branch head. This syntax can be used with any Git command

1643 +that accepts a commit, not just with `git log`. Some other examples:

1644

1645 -------------------------------------------------

1646 $ git show master@{2} # See where the branch pointed 2,

@@ -1743,8 +1744,8 @@ one step:

1744 $ git pull origin master

1745 -------------------------------------------------

1746

1746 -In fact, if you have "master" checked out, then this branch has been

1747 -configured by "git clone" to get changes from the HEAD branch of the

1747 +In fact, if you have `master` checked out, then this branch has been

1748 +configured by `git clone` to get changes from the HEAD branch of the

1749 origin repository. So often you can

1750 accomplish the above with just a simple

1751

@@ -1759,11 +1760,11 @@ the current branch.

1760 More generally, a branch that is created from a remote-tracking branch

1761 will pull

1762 by default from that branch. See the descriptions of the

1762 -branch.<name>.remote and branch.<name>.merge options in

1763 +`branch.<name>.remote` and `branch.<name>.merge` options in

1764 linkgit:git-config[1], and the discussion of the `--track` option in

1765 linkgit:git-checkout[1], to learn how to control these defaults.

1766

1766 -In addition to saving you keystrokes, "git pull" also helps you by

1767 +In addition to saving you keystrokes, `git pull` also helps you by

1768 producing a default commit message documenting the branch and

1769 repository that you pulled from.

1770

@@ -1771,7 +1772,7 @@ repository that you pulled from.

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

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

1774

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

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

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

1777 the commands

1778

@@ -1796,7 +1797,7 @@ $ git format-patch origin

1797 -------------------------------------------------

1798

1799 will produce a numbered series of files in the current directory, one

1799 -for each patch in the current branch but not in origin/HEAD.

1800 +for each patch in the current branch but not in `origin/HEAD`.

1801

1802 `git format-patch` can include an initial "cover letter". You can insert

1803 commentary on individual patches after the three dash line which

@@ -1818,7 +1819,7 @@ Importing patches to a project

1819 Git also provides a tool called linkgit:git-am[1] (am stands for

1820 "apply mailbox"), for importing such an emailed series of patches.

1821 Just save all of the patch-containing messages, in order, into a

1821 -single mailbox file, say "patches.mbox", then run

1822 +single mailbox file, say `patches.mbox`, then run

1823

1824 -------------------------------------------------

1825 $ git am -3 patches.mbox

@@ -1826,7 +1827,7 @@ $ git am -3 patches.mbox

1827

1828 Git will apply each patch in order; if any conflicts are found, it

1829 will stop, and you can fix the conflicts as described in

1829 -"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells

1830 +"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells

1831 Git to perform a merge; if you would prefer it just to abort and

1832 leave your tree and index untouched, you may omit that option.)

1833

@@ -1902,7 +1903,7 @@ We explain how to do this in the following sections.

1903 Setting up a public repository

1904 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1905

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

1906 +Assume your personal repository is in the directory `~/proj`. We

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

1908 is meant to be public:

1909

@@ -1912,10 +1913,10 @@ $ touch proj.git/git-daemon-export-ok

1913 -------------------------------------------------

1914

1915 The resulting directory proj.git contains a "bare" git repository--it is

1915 -just the contents of the ".git" directory, without any files checked out

1916 +just the contents of the `.git` directory, without any files checked out

1917 around it.

1918

1918 -Next, copy proj.git to the server where you plan to host the

1919 +Next, copy `proj.git` to the server where you plan to host the

1920 public repository. You can use scp, rsync, or whatever is most

1921 convenient.

1922

@@ -1926,8 +1927,8 @@ Exporting a Git repository via the Git protocol

1927 This is the preferred method.

1928

1929 If someone else administers the server, they should tell you what

1929 -directory to put the repository in, and what git:// URL it will appear

1930 -at. You can then skip to the section

1930 +directory to put the repository in, and what `git://` URL it will

1931 +appear at. You can then skip to the section

1932 "<<pushing-changes-to-a-public-repository,Pushing changes to a public

1933 repository>>", below.

1934

@@ -1962,7 +1963,7 @@ $ mv hooks/post-update.sample hooks/post-update

1963 (For an explanation of the last two lines, see

1964 linkgit:git-update-server-info[1] and linkgit:githooks[5].)

1965

1965 -Advertise the URL of proj.git. Anybody else should then be able to

1966 +Advertise the URL of `proj.git`. Anybody else should then be able to

1967 clone or pull from that URL, for example with a command line like:

1968

1969 -------------------------------------------------

@@ -1985,8 +1986,8 @@ access, which you will need to update the public repository with the

1986 latest changes created in your private repository.

1987

1988 The simplest way to do this is using linkgit:git-push[1] and ssh; to

1988 -update the remote branch named "master" with the latest state of your

1989 -branch named "master", run

1989 +update the remote branch named `master` with the latest state of your

1990 +branch named `master`, run

1991

1992 -------------------------------------------------

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

@@ -2002,7 +2003,7 @@ As with `git fetch`, `git push` will complain if this does not result in a

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

2004 handling this case.

2005

2005 -Note that the target of a "push" is normally a

2006 +Note that the target of a `push` is normally a

2007 <<def_bare_repository,bare>> repository. You can also push to a

2008 repository that has a checked-out working tree, but a push to update the

2009 currently checked-out branch is denied by default to prevent confusion.

@@ -2030,9 +2031,9 @@ which lets you do the same push with just

2031 $ git push public-repo master

2032 -------------------------------------------------

2033

2033 -See the explanations of the remote.<name>.url, branch.<name>.remote,

2034 -and remote.<name>.push options in linkgit:git-config[1] for

2035 -details.

2034 +See the explanations of the `remote.<name>.url`,

2035 +`branch.<name>.remote`, and `remote.<name>.push` options in

2036 +linkgit:git-config[1] for details.

2037

2038 [[forcing-push]]

2039 What to do when a push fails

@@ -2167,7 +2168,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see

2168

2169 Now create the branches in which you are going to work; these start out

2170 at the current tip of origin/master branch, and should be set up (using

2170 -the --track option to linkgit:git-branch[1]) to merge changes in from

2171 +the `--track` option to linkgit:git-branch[1]) to merge changes in from

2172 Linus by default.

2173

2174 -------------------------------------------------

@@ -2186,7 +2187,7 @@ Important note! If you have any local changes in these branches, then

2187 this merge will create a commit object in the history (with no local

2188 changes Git will simply do a "fast-forward" merge). Many people dislike

2189 the "noise" that this creates in the Linux history, so you should avoid

2189 -doing this capriciously in the "release" branch, as these noisy commits

2190 +doing this capriciously in the `release` branch, as these noisy commits

2191 will become part of the permanent history when you ask Linus to pull

2192 from the release branch.

2193

@@ -2228,7 +2229,7 @@ patches), and create a new branch from a recent stable tag of

2229 Linus's branch. Picking a stable base for your branch will:

2230 1) help you: by avoiding inclusion of unrelated and perhaps lightly

2231 tested changes

2231 -2) help future bug hunters that use "git bisect" to find problems

2232 +2) help future bug hunters that use `git bisect` to find problems

2233

2234 -------------------------------------------------

2235 $ git checkout -b speed-up-spinlocks v2.6.35

@@ -2253,9 +2254,9 @@ It is unlikely that you would have any conflicts here ... but you might if you

2254 spent a while on this step and had also pulled new versions from upstream.

2255

2256 Some time later when enough time has passed and testing done, you can pull the

2256 -same branch into the "release" tree ready to go upstream. This is where you

2257 +same branch into the `release` tree ready to go upstream. This is where you

2258 see the value of keeping each patch (or patch series) in its own branch. It

2258 -means that the patches can be moved into the "release" tree in any order.

2259 +means that the patches can be moved into the `release` tree in any order.

2260

2261 -------------------------------------------------

2262 $ git checkout release && git pull . speed-up-spinlocks

@@ -2288,7 +2289,7 @@ If it has been merged, then there will be no output.)

2289

2290 Once a patch completes the great cycle (moving from test to release,

2291 then pulled by Linus, and finally coming back into your local

2291 -"origin/master" branch), the branch for this change is no longer needed.

2292 +`origin/master` branch), the branch for this change is no longer needed.

2293 You detect this when the output from:

2294

2295 -------------------------------------------------

@@ -2303,8 +2304,8 @@ $ git branch -d branchname

2304

2305 Some changes are so trivial that it is not necessary to create a separate

2306 branch and then merge into each of the test and release branches. For

2306 -these changes, just apply directly to the "release" branch, and then

2307 -merge that into the "test" branch.

2307 +these changes, just apply directly to the `release` branch, and then

2308 +merge that into the `test` branch.

2309

2310 After pushing your work to `mytree`, you can use

2311 linkgit:git-request-pull[1] to prepare a "please pull" request message

@@ -2475,8 +2476,8 @@ you are rewriting history.

2476 Keeping a patch series up to date using git rebase

2477 --------------------------------------------------

2478

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

2479 -"origin", and create some commits on top of it:

2479 +Suppose that you create a branch `mywork` on a remote-tracking branch

2480 +`origin`, and create some commits on top of it:

2481

2482 -------------------------------------------------

2483 $ git checkout -b mywork origin

@@ -2488,7 +2489,7 @@ $ git commit

2489 -------------------------------------------------

2490

2491 You have performed no merges into mywork, so it is just a simple linear

2491 -sequence of patches on top of "origin":

2492 +sequence of patches on top of `origin`:

2493

2494 ................................................

2495 o--o--O <-- origin

@@ -2497,7 +2498,7 @@ sequence of patches on top of "origin":

2498 ................................................

2499

2500 Some more interesting work has been done in the upstream project, and

2500 -"origin" has advanced:

2501 +`origin` has advanced:

2502

2503 ................................................

2504 o--o--O--o--o--o <-- origin

@@ -2505,7 +2506,7 @@ Some more interesting work has been done in the upstream project, and

2506 a--b--c <-- mywork

2507 ................................................

2508

2508 -At this point, you could use "pull" to merge your changes back in;

2509 +At this point, you could use `pull` to merge your changes back in;

2510 the result would create a new merge commit, like this:

2511

2512 ................................................

@@ -2524,7 +2525,7 @@ $ git rebase origin

2525 -------------------------------------------------

2526

2527 This will remove each of your commits from mywork, temporarily saving

2527 -them as patches (in a directory named ".git/rebase-apply"), update mywork to

2528 +them as patches (in a directory named `.git/rebase-apply`), update mywork to

2529 point at the latest version of origin, then apply each of the saved

2530 patches to the new mywork. The result will look like:

2531

@@ -2795,10 +2796,10 @@ arbitrary name:

2796 $ git fetch origin todo:my-todo-work

2797 -------------------------------------------------

2798

2798 -The first argument, "origin", just tells Git to fetch from the

2799 +The first argument, `origin`, just tells Git to fetch from the

2800 repository you originally cloned from. The second argument tells Git

2800 -to fetch the branch named "todo" from the remote repository, and to

2801 -store it locally under the name refs/heads/my-todo-work.

2801 +to fetch the branch named `todo` from the remote repository, and to

2802 +store it locally under the name `refs/heads/my-todo-work`.

2803

2804 You can also fetch branches from other repositories; so

2805

@@ -2806,8 +2807,8 @@ You can also fetch branches from other repositories; so

2807 $ git fetch git://example.com/proj.git master:example-master

2808 -------------------------------------------------

2809

2809 -will create a new branch named "example-master" and store in it the

2810 -branch named "master" from the repository at the given URL. If you

2810 +will create a new branch named `example-master` and store in it the

2811 +branch named `master` from the repository at the given URL. If you

2812 already have a branch named example-master, it will attempt to

2813 <<fast-forwards,fast-forward>> to the commit given by example.com's

2814 master branch. In more detail:

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

2817 git fetch and fast-forwards

2818 ---------------------------

2819

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

2820 +In the previous example, when updating an existing branch, `git fetch`

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

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

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

@@ -2842,11 +2843,11 @@ resulting in a situation like:

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

2844 ................................................

2845

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

2846 +In this case, `git fetch` will fail, and print out a warning.

2847

2848 In that case, you can still force Git to update to the new head, as

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

2849 -situation above this may mean losing the commits labeled "a" and "b",

2850 +situation above this may mean losing the commits labeled `a` and `b`,

2851 unless you've already created a reference of your own pointing to

2852 them.

2853

@@ -2861,7 +2862,7 @@ descendant of the old head, you may force the update with:

2862 $ git fetch git://example.com/proj.git +master:refs/remotes/example/master

2863 -------------------------------------------------

2864

2864 -Note the addition of the "+" sign. Alternatively, you can use the "-f"

2865 +Note the addition of the `+` sign. Alternatively, you can use the `-f`

2866 flag to force updates of all the fetched branches, as in:

2867

2868 -------------------------------------------------

@@ -2875,7 +2876,7 @@ may be lost, as we saw in the previous section.

2876 Configuring remote-tracking branches

2877 ------------------------------------

2878

2878 -We saw above that "origin" is just a shortcut to refer to the

2879 +We saw above that `origin` is just a shortcut to refer to the

2880 repository that you originally cloned from. This information is

2881 stored in Git configuration variables, which you can see using

2882 linkgit:git-config[1]:

@@ -2984,7 +2985,7 @@ Commit Object

2985 ~~~~~~~~~~~~~

2986

2987 The "commit" object links a physical state of a tree with a description

2987 -of how we got there and why. Use the --pretty=raw option to

2988 +of how we got there and why. Use the `--pretty=raw` option to

2989 linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite

2990 commit:

2991

@@ -3026,7 +3027,7 @@ of the tree referred to by this commit with the trees associated with

3027 its parents. In particular, Git does not attempt to record file renames

3028 explicitly, though it can identify cases where the existence of the same

3029 file data at changing paths suggests a rename. (See, for example, the

3029 --M option to linkgit:git-diff[1]).

3030 +`-M` option to linkgit:git-diff[1]).

3031

3032 A commit is usually created by linkgit:git-commit[1], which creates a

3033 commit whose parent is normally the current HEAD, and whose tree is

@@ -3077,7 +3078,7 @@ Blob Object

3078 ~~~~~~~~~~~

3079

3080 You can use linkgit:git-show[1] to examine the contents of a blob; take,

3080 -for example, the blob in the entry for "COPYING" from the tree above:

3081 +for example, the blob in the entry for `COPYING` from the tree above:

3082

3083 ------------------------------------------------

3084 $ git show 6ff87c4664

@@ -3160,14 +3161,14 @@ nLE/L9aUXdWeTFPron96DLA=

3161 See the linkgit:git-tag[1] command to learn how to create and verify tag

3162 objects. (Note that linkgit:git-tag[1] can also be used to create

3163 "lightweight tags", which are not tag objects at all, but just simple

3163 -references whose names begin with "refs/tags/").

3164 +references whose names begin with `refs/tags/`).

3165

3166 [[pack-files]]

3167 How Git stores objects efficiently: pack files

3168 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3169

3170 Newly created objects are initially created in a file named after the

3170 -object's SHA-1 hash (stored in .git/objects).

3171 +object's SHA-1 hash (stored in `.git/objects`).

3172

3173 Unfortunately this system becomes inefficient once a project has a

3174 lot of objects. Try this on an old project:

@@ -3208,9 +3209,9 @@ $ git prune

3209

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

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

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

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

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

3213 -.git/objects directory or by running

3214 +`.git/objects` directory or by running

3215

3216 ------------------------------------------------

3217 $ git count-objects

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

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

3239

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

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

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

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

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

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

@@ -3280,14 +3281,14 @@ $ git show <dangling-blob/tree-sha-goes-here>

3281 ------------------------------------------------

3282

3283 to show what the contents of the blob were (or, for a tree, basically

3283 -what the "ls" for that directory was), and that may give you some idea

3284 +what the `ls` for that directory was), and that may give you some idea

3285 of what the operation was that left that dangling object.

3286

3287 Usually, dangling blobs and trees aren't very interesting. They're

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

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

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

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

3291 +because you interrupted a `git fetch` with ^C or something like that,

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

3293 dangling and useless.

3294

@@ -3298,16 +3299,16 @@ state, you can just prune all unreachable objects:

3299 $ git prune

3300 ------------------------------------------------

3301

3301 -and they'll be gone. But you should only run "git prune" on a quiescent

3302 +and they'll be gone. But you should only run `git prune` on a quiescent

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

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

3305

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

3306 +(The same is true of `git fsck` itself, btw, but since

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

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

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

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

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

3311 +contrast, running `git prune` while somebody is actively changing the

3312 repository is a *BAD* idea).

3313

3314 [[recovering-from-repository-corruption]]

@@ -3345,7 +3346,7 @@ missing blob 4b9458b3786228369c63936db65827de3cc06200

3346 Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6

3347 points to it. If you could find just one copy of that missing blob

3348 object, possibly in some other repository, you could move it into

3348 -.git/objects/4b/9458b3... and be done. Suppose you can't. You can

3349 +`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can

3350 still examine the tree that pointed to it with linkgit:git-ls-tree[1],

3351 which might output something like:

3352

@@ -3360,10 +3361,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8

3361 ------------------------------------------------

3362

3363 So now you know that the missing blob was the data for a file named

3363 -"myfile". And chances are you can also identify the directory--let's

3364 -say it's in "somedirectory". If you're lucky the missing copy might be

3364 +`myfile`. And chances are you can also identify the directory--let's

3365 +say it's in `somedirectory`. If you're lucky the missing copy might be

3366 the same as the copy you have checked out in your working tree at

3366 -"somedirectory/myfile"; you can test whether that's right with

3367 +`somedirectory/myfile`; you can test whether that's right with

3368 linkgit:git-hash-object[1]:

3369

3370 ------------------------------------------------

@@ -3418,7 +3419,7 @@ $ git hash-object -w <recreated-file>

3419

3420 and your repository is good again!

3421

3421 -(Btw, you could have ignored the fsck, and started with doing a

3422 +(Btw, you could have ignored the `fsck`, and started with doing a

3423

3424 ------------------------------------------------

3425 $ git log --raw --all

@@ -3432,7 +3433,7 @@ just missing one particular blob version.

3433 The index

3434 -----------

3435

3435 -The index is a binary file (generally kept in .git/index) containing a

3436 +The index is a binary file (generally kept in `.git/index`) containing a

3437 sorted list of path names, each with permissions and the SHA-1 of a blob

3438 object; linkgit:git-ls-files[1] can show you the contents of the index:

3439

@@ -3572,7 +3573,7 @@ $ ls -a

3573

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

3575

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

3576 +- It clones the submodule from `<repo>` to the given `<path>` under the

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

3578 - It adds the submodule's clone path to the linkgit:gitmodules[5] file and

3579 adds this file to the index, ready to be committed.

@@ -3700,11 +3701,11 @@ Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path

3701

3702 In older Git versions it could be easily forgotten to commit new or modified

3703 files in a submodule, which silently leads to similar problems as not pushing

3703 -the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"

3704 +the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`

3705 in the superproject show submodules as modified when they contain new or

3705 -modified files to protect against accidentally committing such a state. "git

3706 -diff" will also add a "-dirty" to the work tree side when generating patch

3707 -output or used with the --submodule option:

3706 +modified files to protect against accidentally committing such a state. `git

3707 +diff` will also add a `-dirty` to the work tree side when generating patch

3708 +output or used with the `--submodule` option:

3709

3710 -------------------------------------------------

3711 $ git diff

@@ -3880,7 +3881,7 @@ or, if you want to check out all of the index, use `-a`.

3881

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

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

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

3884 +need to use the `-f` flag ('before' the `-a` flag or the filename) to

3885 'force' the checkout.

3886

3887

@@ -3891,7 +3892,7 @@ from one representation to the other:

3892 Tying it all together

3893 ~~~~~~~~~~~~~~~~~~~~~

3894

3894 -To commit a tree you have instantiated with "git write-tree", you'd

3895 +To commit a tree you have instantiated with `git write-tree`, you'd

3896 create a "commit" object that refers to that tree and the history

3897 behind it--most notably the "parent" commits that preceded it in

3898 history.

@@ -4152,8 +4153,9 @@ As a result, the general consistency of an object can always be tested

4153 independently of the contents or the type of the object: all objects can

4154 be validated by verifying that (a) their hashes match the content of the

4155 file and (b) the object successfully inflates to a stream of bytes that

4155 -forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal

4156 -size> {plus} <byte\0> {plus} <binary object data>.

4156 +forms a sequence of

4157 +`<ascii type without space> + <space> + <ascii decimal size> +

4158 +<byte\0> + <binary object data>`.

4159

4160 The structured objects can further have their structure and

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

@@ -4632,10 +4634,10 @@ Think about how to create a clear chapter dependency graph that will

4634 allow people to get to important topics without necessarily reading

4635 everything in between.

4636

4635 -Scan Documentation/ for other stuff left out; in particular:

4637 +Scan `Documentation/` for other stuff left out; in particular:

4638

4639 - howto's

4638 -- some of technical/?

4640 +- some of `technical/`?

4641 - hooks

4642 - list of commands in linkgit:git[1]

4643

user-manual: Standardize backtick quoting