From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id E10EA1F934 for ; Fri, 9 Apr 2021 04:06:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230118AbhDIEGB (ORCPT ); Fri, 9 Apr 2021 00:06:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229874AbhDIEF5 (ORCPT ); Fri, 9 Apr 2021 00:05:57 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95839C061761 for ; Thu, 8 Apr 2021 21:05:42 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id s7so4080565wru.6 for ; Thu, 08 Apr 2021 21:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=B3PlT+z7/8luHDMWQF6XKws730eXPYaB+8e/ORmdUD4=; b=nO6onwErgF12dut+e93gl/akuiJEUopXdKw1q4z+VqTs2FSsrwHuUfJJBRJEaqIodi Ee/X0ZfutlJvNWyXawjO1tCOfNyG2YQVaIDI6TzrvA+wuboQtnGOVyjC/vS145VbFyqE EVl/2xgvy+YQQxxbldoFDckvO8H/YbrDV9XTU0vNM+y6LemRJxLVRNqu4RtIwMK1TgUP Ybddz77XFNNfbG+vU9GO+hsT38OG30JNrI2c32c9e/BkV92Nahn18TanKSlv7rxn77eo o9XX4J7LjCBC8XY296M3UogVsCCd/bI6TRzoDxhCCxdtPHuMioePVy7g7pRHO534RyGz uLXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=B3PlT+z7/8luHDMWQF6XKws730eXPYaB+8e/ORmdUD4=; b=SfIV+7pdzVJ5Vlb35ydjemOTZR2yhoLvW7pWiio7G6375q2x2NhuYkOV2mmkBKgNMQ WlyLcjVfhhW9HPAFzqrC7NrcgO9cHJjGNjtq8svJ/jzfYpp+BndYT4A4yEbR9O1wDWaa A2vUgp4NcKhEL3utsGUCO1JYNLH2j4LQcMfYUNU9u3pU5HM5lL7tu/+ICo2BNfCbHHKG SOV/OMxJbB71QUzCgUaPEjdtq06I8RJHHtjeZp64qTcYh8U/0ZRCfSFPARmAXE9gNhor +VYqdZFZTDyyBFd3Y1vFdgAOX0244C2jspEe2ZSjvHJddg2PZuKdrMAKvVY4jgUCRGze bJ0A== X-Gm-Message-State: AOAM531MSPw4jqKJx9ytsR81zDOmc6nZZnUM8rdfagFtcFNOxwob9+fC LHs+E1gOyi5b9bLZ7zRYB75/G1/hh1buWw== X-Google-Smtp-Source: ABdhPJwMr3bD/fW33IZCL4mPhaTe+QSG0IqQTXHKyp61nttSjwli5WXD/fphDAD2CG+JxFXzpeGWVg== X-Received: by 2002:a5d:484d:: with SMTP id n13mr15735552wrs.71.1617941139557; Thu, 08 Apr 2021 21:05:39 -0700 (PDT) Received: from Inspiron.home (2a01cb04010c420080e637770dc2ae3c.ipv6.abo.wanadoo.fr. [2a01:cb04:10c:4200:80e6:3777:dc2:ae3c]) by smtp.gmail.com with ESMTPSA id c9sm2064636wrr.78.2021.04.08.21.05.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 21:05:38 -0700 (PDT) From: Firmin Martin To: git@vger.kernel.org Cc: Firmin Martin Subject: [RFC PATCH v1 02/13] doc: typeset branches and remotes in monospace Date: Fri, 9 Apr 2021 06:02:50 +0200 Message-Id: <20210409040301.3260358-3-firminmartin24@gmail.com> X-Mailer: git-send-email 2.31.1.133.g84d06cdc06 In-Reply-To: <20210409040301.3260358-1-firminmartin24@gmail.com> References: <20210409040301.3260358-1-firminmartin24@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Wrap branch and remote names with backticks as indicated in the CodingGuidelines. Signed-off-by: Firmin Martin --- Documentation/diff-options.txt | 2 +- Documentation/git-add.txt | 10 +-- Documentation/git-am.txt | 4 +- Documentation/git-archimport.txt | 2 +- Documentation/git-bisect-lk2009.txt | 10 +-- Documentation/git-bisect.txt | 6 +- Documentation/git-branch.txt | 22 +++--- Documentation/git-bundle.txt | 6 +- Documentation/git-check-ref-format.txt | 2 +- Documentation/git-checkout.txt | 2 +- Documentation/git-cherry-pick.txt | 22 +++--- Documentation/git-cherry.txt | 4 +- Documentation/git-clone.txt | 16 ++--- Documentation/git-commit-tree.txt | 2 +- Documentation/git-commit.txt | 6 +- Documentation/git-config.txt | 2 +- Documentation/git-cvsimport.txt | 8 +-- Documentation/git-cvsserver.txt | 2 +- Documentation/git-describe.txt | 6 +- Documentation/git-diff-index.txt | 6 +- Documentation/git-diff.txt | 20 +++--- Documentation/git-fast-export.txt | 16 ++--- Documentation/git-fetch-pack.txt | 2 +- Documentation/git-fetch.txt | 4 +- Documentation/git-filter-branch.txt | 2 +- Documentation/git-fmt-merge-msg.txt | 4 +- Documentation/git-for-each-ref.txt | 12 ++-- Documentation/git-format-patch.txt | 4 +- Documentation/git-http-push.txt | 6 +- Documentation/git-log.txt | 8 +-- Documentation/git-ls-remote.txt | 2 +- Documentation/git-merge.txt | 2 +- Documentation/git-notes.txt | 12 ++-- Documentation/git-p4.txt | 4 +- Documentation/git-pull.txt | 4 +- Documentation/git-push.txt | 8 +-- Documentation/git-read-tree.txt | 4 +- Documentation/git-rebase.txt | 92 +++++++++++++------------- Documentation/git-reflog.txt | 4 +- Documentation/git-request-pull.txt | 2 +- Documentation/git-rerere.txt | 34 +++++----- Documentation/git-reset.txt | 6 +- Documentation/git-rev-parse.txt | 4 +- Documentation/git-revert.txt | 8 +-- Documentation/git-rm.txt | 2 +- Documentation/git-show-ref.txt | 2 +- Documentation/git-show.txt | 2 +- Documentation/git-stash.txt | 8 +-- Documentation/git-status.txt | 12 ++-- Documentation/git-submodule.txt | 28 ++++---- Documentation/git-svn.txt | 20 +++--- Documentation/git-switch.txt | 10 +-- Documentation/git-symbolic-ref.txt | 2 +- Documentation/git-tag.txt | 2 +- Documentation/git-update-ref.txt | 4 +- Documentation/git-worktree.txt | 2 +- Documentation/git.txt | 4 +- Documentation/gitcli.txt | 2 +- Documentation/gitcore-tutorial.txt | 36 +++++----- Documentation/giteveryday.txt | 16 ++--- Documentation/githooks.txt | 8 +-- Documentation/gitk.txt | 2 +- Documentation/gitnamespaces.txt | 2 +- Documentation/gitremote-helpers.txt | 6 +- Documentation/gitrepository-layout.txt | 4 +- Documentation/gittutorial-2.txt | 2 +- Documentation/gittutorial.txt | 44 ++++++------ Documentation/gitweb.txt | 4 +- Documentation/gitworkflows.txt | 70 ++++++++++---------- Documentation/glossary-content.txt | 12 ++-- Documentation/rev-list-options.txt | 2 +- Documentation/revisions.txt | 52 +++++++-------- Documentation/user-manual.txt | 78 +++++++++++----------- 73 files changed, 421 insertions(+), 421 deletions(-) diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 13e0753862..e4ac746428 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -803,7 +803,7 @@ endif::git-format-patch[] Ignore changes to submodules in the diff generation. can be either "none", "untracked", "dirty" or "all", which is the default. Using "none" will consider the submodule modified when it either contains - untracked or modified files or its HEAD differs from the commit recorded + untracked or modified files or its `HEAD` differs from the commit recorded in the superproject and can be used to override any settings of the 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When "untracked" is used submodules are not considered dirty when they only diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 6a7cb07a8a..8ec99c5c12 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -256,7 +256,7 @@ The main command loop has 6 subcommands (plus help and quit). status:: - This shows the change between HEAD and index (i.e. what will be + This shows the change between `HEAD` and index (i.e. what will be committed if you say `git commit`), and between index and working tree files (i.e. what you could stage further before `git commit` using `git add`) for each path. A sample output @@ -268,7 +268,7 @@ status:: 2: +403/-35 +1/-1 git-add--interactive.perl ------------ + -It shows that foo.png has differences from HEAD (but that is +It shows that foo.png has differences from `HEAD` (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, @@ -311,7 +311,7 @@ revert:: This has a very similar UI to 'update', and the staged information for selected paths are reverted to that of the - HEAD version. Reverting new paths makes them untracked. + `HEAD` version. Reverting new paths makes them untracked. add untracked:: @@ -350,7 +350,7 @@ variable `interactive.singleKey` to `true`. diff:: This lets you review what will be committed (i.e. between - HEAD and index). + `HEAD` and index). EDITING PATCHES @@ -389,7 +389,7 @@ There are also more complex operations that can be performed. But beware that because the patch is applied only to the index and not the working tree, the working tree will appear to "undo" the change in the index. For example, introducing a new line into the index that is in neither -the HEAD nor the working tree will stage the new line for commit, but +the `HEAD` nor the working tree will stage the new line for commit, but the line will appear to be reverted in the working tree. Avoid using these constructs, or do so with extreme caution. diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index decd8ae122..cd56054be0 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -176,7 +176,7 @@ default. You can use `--no-utf8` to override this. Restore the original branch and abort the patching operation. --quit:: - Abort the patching operation but keep HEAD and the index + Abort the patching operation but keep `HEAD` and the index untouched. --show-current-patch[=(diff|raw)]:: @@ -229,7 +229,7 @@ operation is finished, so if you decide to start over from scratch, run `git am --abort` before running the command with mailbox names. -Before any patches are applied, ORIG_HEAD is set to the tip of the +Before any patches are applied, `ORIG_HEAD` is set to the tip of the current branch. This is useful if you have problems with multiple commits, like running 'git am' on the wrong branch or an error in the commits that is more easily fixed by changing the mailbox (e.g. diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index b477e3c495..6e2dec5ef1 100644 --- a/Documentation/git-archimport.txt +++ b/Documentation/git-archimport.txt @@ -45,7 +45,7 @@ archives that it imports, it is also possible to specify Git branch names manually. To do so, write a Git branch name after each parameter, separated by a colon. This way, you can shorten the Arch branch names and convert Arch jargon to Git jargon, for example mapping a -"PROJECT{litdd}devo{litdd}VERSION" branch to "master". +"PROJECT{litdd}devo{litdd}VERSION" branch to `master`. Associating multiple Arch branches to one Git branch is possible; the result will make the most sense only if no commits are made to the first diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index f3d9566c89..1276424d65 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -767,8 +767,8 @@ They cannot be on a branch that has no link with the branch of the bad commit and yet not be neither one of its ancestor nor one of its descendants. -For example, there can be a "main" branch, and a "dev" branch that was -forked of the main branch at a commit named "D" like this: +For example, there can be a `main` branch, and a `dev` branch that was +forked of the `main` branch at a commit named "D" like this: ------------- A-B-C-D-E-F-G <--main @@ -776,7 +776,7 @@ A-B-C-D-E-F-G <--main H-I-J <--dev ------------- -The commit "D" is called a "merge base" for branch "main" and "dev" +The commit "D" is called a "merge base" for branch `main` and `dev` because it's the best common ancestor for these branches for a merge. Now let's suppose that commit J is bad and commit G is good and that @@ -794,7 +794,7 @@ H-I-J ------------- But what happens if the first bad commit is "B" and if it has been -fixed in the "main" branch by commit "F"? +fixed in the `main` branch by commit "F"? The result of such a bisection would be that we would find that H is the first bad commit, when in fact it's B. So that would be wrong! @@ -1229,7 +1229,7 @@ message or the author. And it can also be used instead of git "grafts" to link a repository with another old repository. In fact it's this last feature that "sold" it to the Git community, so -it is now in the "master" branch of Git's Git repository and it should +it is now in the `master` branch of Git's Git repository and it should be released in Git 1.6.5 in October or November 2009. One problem with "git replace" is that currently it stores all the diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index fbb39fbdf5..ff50c66e29 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -98,7 +98,7 @@ Bisect reset ~~~~~~~~~~~~ After a bisect session, to clean up the bisection state and return to -the original HEAD, issue the following command: +the original `HEAD`, issue the following command: ------------------------------------------------ $ git bisect reset @@ -379,7 +379,7 @@ branch contained broken or non-buildable commits, but the merge itself was OK. EXAMPLES -------- -* Automatically bisect a broken build between v1.2 and HEAD: +* Automatically bisect a broken build between v1.2 and `HEAD`: + ------------ $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good @@ -387,7 +387,7 @@ $ git bisect run make # "make" builds the app $ git bisect reset # quit the bisect session ------------ -* Automatically bisect a test failure between origin and HEAD: +* Automatically bisect a test failure between `origin` and `HEAD`: + ------------ $ git bisect start HEAD origin -- # HEAD is bad, origin is good diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 271b4ee34e..fa38fa4dc1 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -175,7 +175,7 @@ This option is only applicable in non-verbose mode. the pattern(s). --show-current:: - Print the name of the current branch. In detached HEAD state, + Print the name of the current branch. In detached `HEAD` state, nothing is printed. -v:: @@ -186,7 +186,7 @@ This option is only applicable in non-verbose mode. relationship to upstream branch (if any). If given twice, print the path of the linked worktree (if any) and the name of the upstream branch, as well (see also `git remote show `). Note that the - current worktree's HEAD will not have its path printed (it will always + current worktree's `HEAD` will not have its path printed (it will always be your current directory). -q:: @@ -250,15 +250,15 @@ start-point is either a local or remote-tracking branch. --no-contains []:: Only list branches which don't contain the specified commit - (HEAD if not specified). Implies `--list`. + (`HEAD` if not specified). Implies `--list`. --merged []:: Only list branches whose tips are reachable from the - specified commit (HEAD if not specified). Implies `--list`. + specified commit (`HEAD` if not specified). Implies `--list`. --no-merged []:: Only list branches whose tips are not reachable from the - specified commit (HEAD if not specified). Implies `--list`. + specified commit (`HEAD` if not specified). Implies `--list`. :: The name of the branch to create or delete. @@ -269,7 +269,7 @@ start-point is either a local or remote-tracking branch. :: The new branch head will point to this commit. It may be given as a branch name, a commit-id, or a tag. If this - option is omitted, the current HEAD will be used instead. + option is omitted, the current `HEAD` will be used instead. :: The name of an existing branch to rename. @@ -286,7 +286,7 @@ start-point is either a local or remote-tracking branch. for-each-ref`. Sort order defaults to the value configured for the `branch.sort` variable if exists, or to sorting based on the full refname (including `refs/...` prefix). This lists - detached HEAD (if present) first, then local branches and + detached `HEAD` (if present) first, then local branches and finally remote-tracking branches. See linkgit:git-config[1]. @@ -328,10 +328,10 @@ $ git branch -d -r origin/todo origin/html origin/man <1> $ git branch -D test <2> ------------ + -<1> Delete the remote-tracking branches "todo", "html" and "man". The next +<1> Delete the remote-tracking branches `todo`, `html` and `man`. The next 'fetch' or 'pull' will create them again unless you configure them not to. See linkgit:git-fetch[1]. -<2> Delete the "test" branch even if the "master" branch (or whichever branch +<2> Delete the `test` branch even if the `master` branch (or whichever branch is currently checked out) does not have all commits from the test branch. Listing branches from a specific remote:: @@ -365,10 +365,10 @@ serve four related but different purposes: contain the specified . - `--merged` is used to find all branches which can be safely deleted, - since those branches are fully contained by HEAD. + since those branches are fully contained by `HEAD`. - `--no-merged` is used to find branches which are candidates for merging - into HEAD, since those branches are not fully contained by HEAD. + into `HEAD`, since those branches are not fully contained by `HEAD`. include::ref-reachability-filters.txt[] diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 4f1e59a3b2..20da47cbd6 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -68,7 +68,7 @@ unbundle :: 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES below), that specifies the specific objects and references to transport. For example, `master~10..master` causes the - current master reference to be packaged along with all objects + current `master` reference to be packaged along with all objects added since its 10th ancestor commit. There is no explicit limit to the number of references and objects that may be packaged. @@ -146,7 +146,7 @@ Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B. For whatever reason, direct connection between A and B is not allowed, but we can move data from A to B via some mechanism (CD, email, etc.). -We want to update R2 with development made on the branch master in R1. +We want to update R2 with development made on the branch `master` in R1. To bootstrap the process, you can first create a bundle that does not have any basis. You can use a tag to remember up to what commit you last @@ -167,7 +167,7 @@ create a new repository on machine B by cloning from it: machineB$ git clone -b master /home/me/tmp/file.bundle R2 ---------------- -This will define a remote called "origin" in the resulting repository that +This will define a remote called `origin` in the resulting repository that lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will have an entry like this: diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index ee6a4144fb..f39622c0da 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -80,7 +80,7 @@ reference name expressions (see linkgit:gitrevisions[7]): With the `--branch` option, the command takes a name and checks if it can be used as a valid branch name (e.g. when creating a new branch). But be cautious when using the -previous checkout syntax that may refer to a detached HEAD state. +previous checkout syntax that may refer to a detached `HEAD` state. The rule `git check-ref-format --branch $name` implements may be stricter than what `git check-ref-format refs/heads/$name` says (e.g. a dash may appear at the beginning of a ref component, diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 3336b8dace..192dbfe9b0 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -189,7 +189,7 @@ one for the purposes of disambiguation, even if the `` isn't unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin` to always checkout remote branches from there if `` is ambiguous but exists on the -'origin' remote. See also `checkout.defaultRemote` in +`origin` remote. See also `checkout.defaultRemote` in linkgit:git-config[1]. + `--guess` is the default behavior. Use `--no-guess` to disable it. diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 0127f56204..6069cc77a0 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -17,7 +17,7 @@ DESCRIPTION Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your -working tree to be clean (no modifications from the HEAD commit). +working tree to be clean (no modifications from the `HEAD` commit). When it is not obvious how to apply a change, the following happens: @@ -96,7 +96,7 @@ OPTIONS each named commit to your working tree and the index, without making any commit. In addition, when this option is used, your index does not have to match the - HEAD commit. The cherry-pick is done against the + `HEAD` commit. The cherry-pick is done against the beginning state of your index. + This is useful when cherry-picking more than one commits' @@ -117,7 +117,7 @@ effect to your index in a row. earlier `--gpg-sign`. --ff:: - If the current HEAD is the same as the parent of the + If the current `HEAD` is the same as the parent of the cherry-pick'ed commit, then a fast forward to this commit will be performed. @@ -176,13 +176,13 @@ EXAMPLES `git cherry-pick ^HEAD master`:: Apply the changes introduced by all commits that are ancestors - of master but not of HEAD to produce new commits. + of `master` but not of `HEAD` to produce new commits. `git cherry-pick maint next ^master`:: `git cherry-pick maint master..next`:: Apply the changes introduced by all commits that are - ancestors of maint or next, but not master or any of its + ancestors of `maint` or `next`, but not `master` or any of its ancestors. Note that the latter does not mean `maint` and everything between `master` and `next`; specifically, `maint` will not be used if it is included in `master`. @@ -190,27 +190,27 @@ EXAMPLES `git cherry-pick master~4 master~2`:: Apply the changes introduced by the fifth and third last - commits pointed to by master and create 2 new commits with + commits pointed to by `master` and create 2 new commits with these changes. `git cherry-pick -n master~1 next`:: Apply to the working tree and the index the changes introduced - by the second last commit pointed to by master and by the last + by the second last commit pointed to by `master` and by the last commit pointed to by next, but do not create any commit with these changes. `git cherry-pick --ff ..next`:: - If history is linear and HEAD is an ancestor of next, update - the working tree and advance the HEAD pointer to match next. + If history is linear and `HEAD` is an ancestor of next, update + the working tree and advance the `HEAD` pointer to match next. Otherwise, apply the changes introduced by those commits that - are in next but not HEAD to the current branch, creating a new + are in next but not `HEAD` to the current branch, creating a new commit for each new change. `git rev-list --reverse master -- README | git cherry-pick -n --stdin`:: - Apply the changes introduced by all commits on the master + Apply the changes introduced by all commits on the `master` branch that touched README to the working tree and index, so the result can be inspected and made into a single new commit if suitable. diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt index 0ea921a593..4374f398fa 100644 --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -31,10 +31,10 @@ OPTIONS :: Upstream branch to search for equivalent commits. - Defaults to the upstream branch of HEAD. + Defaults to the upstream branch of `HEAD`. :: - Working branch; defaults to HEAD. + Working branch; defaults to `HEAD`. :: Do not report commits up to (and including) limit. diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 22334771d1..8cd602a852 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -30,8 +30,8 @@ currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without -arguments will in addition merge the remote master branch into the -current master branch, if any (this is untrue when `--single-branch` +arguments will in addition merge the remote `master` branch into the +current `master` branch, if any (this is untrue when `--single-branch` is given; see below). This default configuration is achieved by creating references to @@ -147,7 +147,7 @@ objects from the source repository into a pack in the cloned repository. -n:: --no-checkout:: - No checkout of HEAD is performed after the clone is complete. + No checkout of `HEAD` is performed after the clone is complete. --[no-]reject-shallow:: Fail if the source repository is a shallow repository. @@ -198,11 +198,11 @@ objects from the source repository into a pack in the cloned repository. -b :: --branch :: - Instead of pointing the newly created HEAD to the branch pointed - to by the cloned repository's HEAD, point to `` branch + Instead of pointing the newly created `HEAD` to the branch pointed + to by the cloned repository's `HEAD`, point to `` branch instead. In a non-bare repository, this is the branch that will be checked out. - `--branch` can also take tags and detaches the HEAD at that commit + `--branch` can also take tags and detaches the `HEAD` at that commit in the resulting repository. -u :: @@ -224,7 +224,7 @@ objects from the source repository into a pack in the cloned repository. linkgit:git-config[1] (e.g., `core.eol=true`). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add - additional fetch refspecs to the origin remote. + additional fetch refspecs to the `origin` remote. + Due to limitations of the current implementation, some configuration variables do not take effect until after the initial fetch and checkout. @@ -253,7 +253,7 @@ corresponding `--mirror` and `--no-tags` options instead. branch remote's `HEAD` points at. Further fetches into the resulting repository will only update the remote-tracking branch for the branch this option was used for the - initial cloning. If the HEAD at the remote did not point at any + initial cloning. If the `HEAD` at the remote did not point at any branch when `--single-branch` clone was made, no remote-tracking branch is created. diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt index 2e2c581098..b76a825c94 100644 --- a/Documentation/git-commit-tree.txt +++ b/Documentation/git-commit-tree.txt @@ -36,7 +36,7 @@ While a tree represents a particular directory state of a working directory, a commit represents that state in "time", and explains how to get there. -Normally a commit would identify a new "HEAD" state, and while Git +Normally a commit would identify a new `HEAD` state, and while Git doesn't care where you save the note about that state, in practice we tend to just write the result to the file that is pointed at by `.git/HEAD`, so that we can always see what the last committed diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 6d0d663b50..f507ae00a1 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -21,9 +21,9 @@ DESCRIPTION ----------- Create a new commit containing the current contents of the index and the given log message describing the changes. The new commit is a -direct child of HEAD, usually the tip of the current branch, and the +direct child of `HEAD`, usually the tip of the current branch, and the branch is updated to point to it (unless no branch is associated with -the working tree, in which case HEAD is "detached" as described in +the working tree, in which case `HEAD` is "detached" as described in linkgit:git-checkout[1]). The content to be committed can be specified in several ways: @@ -352,7 +352,7 @@ configuration variable documented in linkgit:git-config[1]. -v:: --verbose:: - Show unified diff between the HEAD commit and what + Show unified diff between the `HEAD` commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index b93394ea45..e6d70ffda1 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -148,7 +148,7 @@ See also <>. --blob blob:: Similar to `--file` but use the given blob instead of a file. E.g. you can use 'master:.gitmodules' to read values from the file - '.gitmodules' in the master branch. See "SPECIFYING REVISIONS" + '.gitmodules' in the `master` branch. See "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7] for a more complete list of ways to spell blob names. diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 143c726511..95fa94de74 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -35,7 +35,7 @@ Please see the section <> for further reference. You should *never* do any work of your own on the branches that are created by 'git cvsimport'. By default initial import will create and populate a -"master" branch from the CVS repository's main branch which you're free +`master` branch from the CVS repository's main branch which you're free to work with; after that, you need to 'git merge' incremental imports, or any CVS branches, yourself. It is advisable to specify a named remote via `-r` to separate and protect the incoming branches. @@ -71,11 +71,11 @@ OPTIONS -r :: The Git remote to import this CVS repository into. Moves all CVS branches into remotes// - akin to the way 'git clone' uses 'origin' by default. + akin to the way 'git clone' uses `origin` by default. -o :: When no remote is specified (via `-r`) the `HEAD` branch - from CVS is imported to the 'origin' branch within the Git + from CVS is imported to the `origin` branch within the Git repository, as `HEAD` already has a special meaning for Git. When a remote is specified the `HEAD` branch is named remotes//master mirroring 'git clone' behaviour. @@ -200,7 +200,7 @@ Problems related to timestamps: to be used for ordering commits changes may show up in the wrong order. * If any files were ever "cvs import"ed more than once (e.g., import of - more than one vendor release) the HEAD contains the wrong content. + more than one vendor release) the `HEAD` contains the wrong content. * If the timestamp order of different files cross the revision order within the commit matching time window the order of commits may be wrong. diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index 955bae46c9..c6a926d8d2 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -199,7 +199,7 @@ allowing access over SSH. 5. Clients should now be able to check out the project. Use the CVS 'module' name to indicate what Git 'head' you want to check out. This also sets the name of your newly checked-out directory, unless you tell it otherwise with - `-d `. For example, this checks out 'master' branch to the + `-d `. For example, this checks out `master` branch to the `project-master` directory: + ------ diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index a3f015743b..7d2649c477 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -30,17 +30,17 @@ If the given object refers to a blob, it will be described as `:`, such that the blob can be found at `` in the ``, which itself describes the first commit in which this blob occurs in a reverse revision walk -from HEAD. +from `HEAD`. OPTIONS ------- ...:: - Commit-ish object names to describe. Defaults to HEAD if omitted. + Commit-ish object names to describe. Defaults to `HEAD` if omitted. --dirty[=]:: --broken[=]:: Describe the state of the working tree. When the working - tree matches HEAD, the output is the same as "git describe + tree matches `HEAD`, the output is the same as "git describe HEAD". If the working tree has local modification "-dirty" is appended to it. If a repository is corrupt and Git cannot determine if there is local modification, Git will diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index 27acb31cbf..10e79a29aa 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -31,7 +31,7 @@ include::diff-options.txt[] --merge-base:: Instead of comparing directly, use the merge base - between and HEAD instead. must be a + between and `HEAD` instead. must be a commit. -m:: @@ -53,7 +53,7 @@ CACHED MODE ----------- If `--cached` is specified, it allows you to ask: - show me the differences between HEAD and the current index + show me the differences between `HEAD` and the current index contents (the ones I'd write using 'git write-tree') For example, let's say that you have worked on your working directory, updated @@ -89,7 +89,7 @@ the more useful of the two in that what it does can't be emulated with a 'git write-tree' + 'git diff-tree'. Thus that's the default mode. The non-cached version asks the question: - show me the differences between HEAD and the currently checked out + show me the differences between `HEAD` and the currently checked out tree - index contents _and_ files that aren't up to date which is obviously a very useful question too, since that tells you what diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 9f4b46c910..33a47958bc 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -45,20 +45,20 @@ files on disk. This form is to view the changes you staged for the next commit relative to the named . Typically you would want comparison with the latest commit, so if you - do not give , it defaults to HEAD. - If HEAD does not exist (e.g. unborn branches) and + do not give , it defaults to `HEAD`. + If `HEAD` does not exist (e.g. unborn branches) and is not given, it shows all staged changes. `--staged` is a synonym of `--cached`. + If `--merge-base` is given, instead of using , use the merge base -of and HEAD. `git diff --merge-base A` is equivalent to +of and `HEAD`. `git diff --merge-base A` is equivalent to `git diff $(git merge-base A HEAD)`. 'git diff' [] [--] [...]:: This form is to view the changes you have in your working tree relative to the named . You can - use HEAD to compare it with the latest commit, or a + use `HEAD` to compare it with the latest commit, or a branch name to compare with the tip of a different branch. @@ -85,7 +85,7 @@ If `--merge-base` is given, use the merge base of the two commits for the This is synonymous to the earlier form (without the `..`) for viewing the changes between two arbitrary . If on one side is omitted, it will have the same effect as - using HEAD instead. + using `HEAD` instead. 'git diff' [] \... [--] [...]:: @@ -93,7 +93,7 @@ If `--merge-base` is given, use the merge base of the two commits for the and up to the second , starting at a common ancestor of both . `git diff A...B` is equivalent to `git diff $(git merge-base A B) B`. You can omit any one - of , which has the same effect as using HEAD instead. + of , which has the same effect as using `HEAD` instead. Just in case you are doing something exotic, it should be noted that all of the in the above description, except @@ -165,8 +165,8 @@ $ git diff HEAD^ HEAD <3> ------------ + <1> Instead of using the tip of the current branch, compare with the - tip of "test" branch. -<2> Instead of comparing with the tip of "test" branch, compare with + tip of `test` branch. +<2> Instead of comparing with the tip of `test` branch, compare with the tip of the current branch, but limit the comparison to the file "test". <3> Compare the version before the last commit and the last commit. @@ -179,9 +179,9 @@ $ git diff topic..master <2> $ git diff topic...master <3> ------------ + -<1> Changes between the tips of the topic and the master branches. +<1> Changes between the tips of the `topic` and the `master` branches. <2> Same as above. -<3> Changes that occurred on the master branch since when the topic +<3> Changes that occurred on the `master` branch since when the `topic` branch was started off it. Limiting the diff output:: diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index a1c02918f9..3a6a77abac 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -126,10 +126,10 @@ by keeping the marks the same across runs. --reference-excluded-parents:: By default, running a command such as `git fast-export - master~5..master` will not include the commit master{tilde}5 - and will make master{tilde}4 no longer have master{tilde}5 as - a parent (though both the old master{tilde}4 and new - master{tilde}4 will have all the same files). Use + master~5..master` will not include the commit `master~5` + and will make `master~4` no longer have `master~5` as + a parent (though both the old `master~4` and new + `master~4` will have all the same files). Use `--reference-excluded-parents` to instead have the stream refer to commits in the excluded range of history by their sha1sum. Note that the resulting stream can only be used by a @@ -158,10 +158,10 @@ by keeping the marks the same across runs. A list of arguments, acceptable to 'git rev-parse' and 'git rev-list', that specifies the specific objects and references to export. For example, `master~10..master` causes the - current master reference to be exported along with all objects + current `master` reference to be exported along with all objects added since its 10th ancestor commit and (unless the `--reference-excluded-parents` option is specified) all files - common to master{tilde}9 and master{tilde}10. + common to `master~9` and `master~10`. EXAMPLES -------- @@ -180,8 +180,8 @@ $ git fast-export master~5..master | git fast-import ----------------------------------------------------- -This makes a new branch called 'other' from 'master~5..master' -(i.e. if 'master' has linear history, it will take the last 5 commits). +This makes a new branch called `other` from `master~5`..`master` +(i.e. if `master` has linear history, it will take the last 5 commits). Note that this assumes that none of the blobs and commit messages referenced by that revision range contains the string diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 88c2b9d426..1f48f89e3e 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -116,7 +116,7 @@ be in a separate packet, and the list must end with a flush packet. ...:: The remote heads to update from. This is relative to - $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When + $GIT_DIR (e.g. `HEAD`, "refs/heads/master"). When unspecified, update from all heads the remote side has. + If the remote has enabled the options `uploadpack.allowTipSHA1InWant`, diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index 85b073a61a..a5ecf00db3 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -87,10 +87,10 @@ This configuration is used in two ways: s given on the command line determine what are to be fetched (e.g. `master` in the example, which is a short-hand for `master:`, which in turn means - "fetch the 'master' branch but I do not explicitly say what + "fetch the `master` branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will - fetch _only_ the 'master' branch. The `remote..fetch` + fetch _only_ the `master` branch. The `remote..fetch` values determine which remote-tracking branch, if any, is updated. When used in this way, the `remote..fetch` values do not have any diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 2de3511459..e2955bc648 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -267,7 +267,7 @@ history, so we also add `--ignore-unmatch`: git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD -------------------------------------------------------------------------- -Now, you will get the rewritten history saved in HEAD. +Now, you will get the rewritten history saved in `HEAD`. To rewrite the repository to look as if `foodir/` had been its project root, and discard all other history: diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index 9004861eae..86fb26dcea 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -65,8 +65,8 @@ $ git fetch origin master $ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD --------- -Print a log message describing a merge of the "master" branch from -the "origin" remote. +Print a log message describing a merge of the `master` branch from +the `origin` remote. SEE ALSO diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index e035edf11d..4bde4f9d05 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -76,18 +76,18 @@ OPTIONS --merged[=]:: Only list refs whose tips are reachable from the - specified commit (HEAD if not specified). + specified commit (`HEAD` if not specified). --no-merged[=]:: Only list refs whose tips are not reachable from the - specified commit (HEAD if not specified). + specified commit (`HEAD` if not specified). --contains[=]:: - Only list refs which contain the specified commit (HEAD if not + Only list refs which contain the specified commit (`HEAD` if not specified). --no-contains[=]:: - Only list refs which don't contain the specified commit (HEAD + Only list refs which don't contain the specified commit (`HEAD` if not specified). --ignore-case:: @@ -169,7 +169,7 @@ push:: ref is configured. HEAD:: - '*' if HEAD matches current ref (the checked out branch), ' ' + '*' if `HEAD` matches current ref (the checked out branch), ' ' otherwise. color:: @@ -201,7 +201,7 @@ if:: everything after %(else) is printed. We ignore space when evaluating the string before %(then), this is useful when we use the %(HEAD) atom which prints either "*" or " " and we - want to apply the 'if' condition only on the 'HEAD' ref. + want to apply the 'if' condition only on the `HEAD` ref. Append ":equals=" or ":notequals=" to compare the value between the %(if:...) and %(then) atoms with the given string. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index ca500ba72c..fd7c6c705b 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -706,7 +706,7 @@ $ git format-patch -k --stdout R1..R2 | git am -3 -k ------------ * Extract all commits which are in the current branch but not in the - origin branch: + `origin` branch: + ------------ $ git format-patch origin @@ -714,7 +714,7 @@ $ git format-patch origin + For each commit a separate file is created in the current directory. -* Extract all commits that lead to 'origin' since the inception of the +* Extract all commits that lead to `origin` since the inception of the project: + ------------ diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt index 5dd4d2b63a..7ba8ea2383 100644 --- a/Documentation/git-http-push.txt +++ b/Documentation/git-http-push.txt @@ -44,12 +44,12 @@ OPTIONS -d:: -D:: Remove from remote repository. The specified branch - cannot be the remote HEAD. If `-d` is specified the following + cannot be the remote `HEAD`. If `-d` is specified the following other conditions must also be met: - - Remote HEAD must resolve to an object that exists locally + - Remote `HEAD` must resolve to an object that exists locally - Specified branch resolves to an object that exists locally - - Specified branch is an ancestor of the remote HEAD + - Specified branch is an ancestor of the remote `HEAD` ...:: The remote refs to update. diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 1bbf865a1b..b306dced1c 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -152,13 +152,13 @@ EXAMPLES `git log --branches --not --remotes=origin`:: Shows all commits that are in any of local branches but not in - any of remote-tracking branches for 'origin' (what you have that - origin doesn't). + any of remote-tracking branches for `origin` (what you have that + `origin` doesn't). `git log master --not --remotes=*/master`:: - Shows all commits that are in local master but not in any remote - repository master branches. + Shows all commits that are in local `master` but not in any remote + repository `master` branches. `git log -p -m --first-parent`:: diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 4cb4e2fd5d..af005ece9a 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -59,7 +59,7 @@ OPTIONS --symref:: In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref. Currently, - upload-pack only shows the symref HEAD, so it will be the only + upload-pack only shows the symref `HEAD`, so it will be the only one shown by ls-remote. --sort=:: diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 3819fadac1..58fd091d73 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -146,7 +146,7 @@ To avoid recording unrelated changes in the merge commit, 'git pull' and 'git merge' will also abort if there are any changes registered in the index relative to the `HEAD` commit. (Special narrow exceptions to this rule may exist depending on which merge -strategy is in use, but generally, the index must match HEAD.) +strategy is in use, but generally, the index must match `HEAD`.) If all named commits are already ancestors of `HEAD`, 'git merge' will exit early with the message "Already up to date." diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index b0a5ab9a72..ef04e3a8ff 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -60,7 +60,7 @@ list:: This is the default subcommand if no subcommand is given. add:: - Add notes for a given object (defaults to HEAD). Abort if the + Add notes for a given object (defaults to `HEAD`). Abort if the object already has notes (use `-f` to overwrite existing notes). However, if you're using `add` interactively (using an editor to supply the notes contents), then - instead of aborting - @@ -69,7 +69,7 @@ add:: copy:: Copy the notes for the first object onto the second object (defaults to - HEAD). Abort if the second object already has notes, or if the first + `HEAD`). Abort if the second object already has notes, or if the first object has none (use -f to overwrite existing notes to the second object). This subcommand is equivalent to: `git notes add [-f] -C $(git notes list ) ` @@ -85,14 +85,14 @@ corresponding . (The optional `` is ignored so that the command can read the input given to the `post-rewrite` hook.) append:: - Append to the notes of an existing object (defaults to HEAD). + Append to the notes of an existing object (defaults to `HEAD`). Creates a new notes object if needed. edit:: - Edit the notes for a given object (defaults to HEAD). + Edit the notes for a given object (defaults to `HEAD`). show:: - Show the notes for a given object (defaults to HEAD). + Show the notes for a given object (defaults to `HEAD`). merge:: Merge the given notes ref into the current notes ref. @@ -110,7 +110,7 @@ When done, the user can either finalize the merge with 'git notes merge --abort'. remove:: - Remove the notes for given objects (defaults to HEAD). When + Remove the notes for given objects (defaults to `HEAD`). When giving zero or one object from the command line, this is equivalent to specifying an empty note message to the `edit` subcommand. diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index d9d29a5efa..ec23ab7d96 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -76,7 +76,7 @@ This: 2. Imports the full contents of the head revision from the given p4 depot path into a single commit in the Git branch 'refs/remotes/p4/master'. + -3. Creates a local branch, 'master' from this remote and checks it out. +3. Creates a local branch, `master` from this remote and checks it out. To reproduce the entire p4 history in Git, use the '@all' modifier on the depot path: @@ -176,7 +176,7 @@ Unshelve Unshelving will take a shelved P4 changelist, and produce the equivalent git commit in the branch refs/remotes/p4-unshelved/. -The git commit is created relative to the current origin revision (HEAD by default). +The git commit is created relative to the current origin revision (`HEAD` by default). A parent commit is created based on the origin, and then the unshelve commit is created based on that. diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index edecf393d3..d9a5507195 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -211,7 +211,7 @@ $ git pull $ git pull origin ------------------------------------------------ + -Normally the branch merged in is the HEAD of the remote repository, +Normally the branch merged in is the `HEAD` of the remote repository, but the choice is determined by the branch..remote and branch..merge options; see linkgit:git-config[1] for details. @@ -221,7 +221,7 @@ branch..merge options; see linkgit:git-config[1] for details. $ git pull origin next ------------------------------------------------ + -This leaves a copy of `next` temporarily in FETCH_HEAD, and +This leaves a copy of `next` temporarily in `FETCH_HEAD`, and updates the remote-tracking branch `origin/next`. The same can be done by invoking fetch and merge: + diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index fc91d41ce0..91dcaa108c 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -667,9 +667,9 @@ made on `satellite`. (e.g. `refs/heads/experimental`), and delete it. `git push origin +dev:master`:: - Update the origin repository's master branch with the dev branch, + Update the `origin` repository's `master` branch with the `dev` branch, allowing non-fast-forward updates. *This can leave unreferenced - commits dangling in the origin repository.* Consider the + commits dangling in the `origin` repository.* Consider the following situation, where a fast-forward is not possible: + ---- @@ -678,7 +678,7 @@ made on `satellite`. X---Y---Z dev ---- + -The above command would change the origin repository to +The above command would change the `origin` repository to + ---- A---B (unnamed branch) @@ -688,7 +688,7 @@ The above command would change the origin repository to + Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by -a `git gc` command on the origin repository. +a `git gc` command on the `origin` repository. include::transfer-data-leaks.txt[] diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index 3f53688170..d22d3855d1 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -118,7 +118,7 @@ OPTIONS --[no-]recurse-submodules:: Using `--recurse-submodules` will update the content of all active submodules according to the commit recorded in the superproject by - calling read-tree recursively, also setting the submodules' HEAD to be + calling read-tree recursively, also setting the submodules' `HEAD` to be detached at that commit. --no-sparse-checkout:: @@ -356,7 +356,7 @@ $ git fetch git://.... linus $ LT=`git rev-parse FETCH_HEAD` ---------------- -Your work tree is still based on your HEAD ($JC), but you have +Your work tree is still based on your `HEAD` ($JC), but you have some edits since. Three-way merge makes sure that you have not added or modified index entries since $JC, and if you haven't, then does the right thing. So with the following sequence: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index f063d54623..bd9f15ea26 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -35,13 +35,13 @@ description on `--fork-point` below); or by `git log HEAD`, if the The current branch is reset to , or if the `--onto` option was supplied. This has the exact same effect as -`git reset --hard ` (or ). ORIG_HEAD is set +`git reset --hard ` (or ). `ORIG_HEAD` is set to point at the tip of the branch before the reset. The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that -any commits in HEAD which introduce the same textual changes as a commit -in HEAD.. are omitted (i.e., a patch already accepted upstream +any commits in `HEAD` which introduce the same textual changes as a commit +in `HEAD`.. are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped). It is possible that a merge failure will prevent this process from being @@ -51,7 +51,7 @@ that caused the merge failure with `git rebase --skip`. To check out the original and remove the .git/rebase-apply working files, use the command `git rebase --abort` instead. -Assume the following history exists and the current branch is "topic": +Assume the following history exists and the current branch is `topic`: ------------ A---B---C topic @@ -101,9 +101,9 @@ Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using `rebase --onto`. -First let's assume your 'topic' is based on branch 'next'. -For example, a feature developed in 'topic' depends on some -functionality which is found in 'next'. +First let's assume your `topic` is based on branch `next`. +For example, a feature developed in `topic` depends on some +functionality which is found in `next'. ------------ o---o---o---o---o master @@ -113,9 +113,9 @@ functionality which is found in 'next'. o---o---o topic ------------ -We want to make 'topic' forked from branch 'master'; for example, -because the functionality on which 'topic' depends was merged into the -more stable 'master' branch. We want our tree to look like this: +We want to make `topic` forked from branch `master`; for example, +because the functionality on which `topic` depends was merged into the +more stable `master` branch. We want our tree to look like this: ------------ o---o---o---o---o master @@ -216,7 +216,7 @@ OPTIONS + As a special case, you may use "A\...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can -leave out at most one of A and B, in which case it defaults to HEAD. +leave out at most one of A and B, in which case it defaults to `HEAD`. --keep-base:: Set the starting point at which to create the new commits to the @@ -242,20 +242,20 @@ See also INCOMPATIBLE OPTIONS below. upstream for the current branch. :: - Working branch; defaults to HEAD. + Working branch; defaults to `HEAD`. --continue:: Restart the rebasing process after having resolved a merge conflict. --abort:: - Abort the rebase operation and reset HEAD to the original + Abort the rebase operation and reset `HEAD` to the original branch. If was provided when the rebase operation was - started, then HEAD will be reset to . Otherwise HEAD + started, then `HEAD` will be reset to . Otherwise `HEAD` will be reset to where it was when the rebase operation was started. --quit:: - Abort the rebase operation but HEAD is not reset back to the + Abort the rebase operation but `HEAD` is not reset back to the original branch. The index and working tree are also left unchanged as a result. If a temporary stash entry was created using `--autostash`, it will be saved to the stash list. @@ -905,7 +905,7 @@ when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with `git rebase --continue`. For example, if you want to reorder the last 5 commits, such that what -was HEAD~4 becomes the new HEAD. To achieve that, you would call +was `HEAD~4` becomes the new `HEAD`. To achieve that, you would call 'git rebase' like this: ---------------------- @@ -925,8 +925,8 @@ like this: ---o---O---P---Q ------------------ -Suppose you want to rebase the side branch starting at "A" to "Q". Make -sure that the current HEAD is "B", and call +Suppose you want to rebase the side branch starting at `A` to `Q`. Make +sure that the current `HEAD` is `B`, and call ----------------------------- $ git rebase -i -r --onto Q O @@ -990,7 +990,7 @@ add other commits. This can be used to split a commit into two: - Mark the commit you want to split with the action "edit". - When it comes to editing that commit, execute `git reset HEAD^`. The - effect is that the HEAD is rewound by one, and the index follows suit. + effect is that the `HEAD` is rewound by one, and the index follows suit. However, the working tree stays the same. - Now add the changes to the index that you want to have in the first @@ -1020,8 +1020,8 @@ from the downstream's point of view. The real fix, however, would be to avoid rebasing the upstream in the first place. To illustrate, suppose you are in a situation where someone develops a -'subsystem' branch, and you are working on a 'topic' that is dependent -on this 'subsystem'. You might end up with a history like the +`subsystem` branch, and you are working on a `topic` that is dependent +on this `subsystem`. You might end up with a history like the following: ------------ @@ -1032,7 +1032,7 @@ following: *---*---* topic ------------ -If 'subsystem' is rebased against 'master', the following happens: +If `subsystem` is rebased against `master`, the following happens: ------------ o---o---o---o---o---o---o---o master @@ -1042,8 +1042,8 @@ If 'subsystem' is rebased against 'master', the following happens: *---*---* topic ------------ -If you now continue development as usual, and eventually merge 'topic' -to 'subsystem', the commits from 'subsystem' will remain duplicated forever: +If you now continue development as usual, and eventually merge `topic` +to `subsystem`, the commits from `subsystem` will remain duplicated forever: ------------ o---o---o---o---o---o---o---o master @@ -1055,20 +1055,20 @@ to 'subsystem', the commits from 'subsystem' will remain duplicated forever: Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to -transplant the commits on 'topic' to the new 'subsystem' tip, i.e., -rebase 'topic'. This becomes a ripple effect: anyone downstream from -'topic' is forced to rebase too, and so on! +transplant the commits on `topic` to the new `subsystem` tip, i.e., +rebase `topic`. This becomes a ripple effect: anyone downstream from +`topic` is forced to rebase too, and so on! There are two kinds of fixes, discussed in the following subsections: Easy case: The changes are literally the same.:: - This happens if the 'subsystem' rebase was a simple rebase and + This happens if the `subsystem` rebase was a simple rebase and had no conflicts. Hard case: The changes are not the same.:: - This happens if the 'subsystem' rebase had conflicts, or used + This happens if the `subsystem` rebase had conflicts, or used `--interactive` to omit, edit, squash, or fixup commits; or if the upstream used one of `commit --amend`, `reset`, or a full history rewriting command like @@ -1079,13 +1079,13 @@ The easy case ~~~~~~~~~~~~~ Only works if the changes (patch IDs based on the diff contents) on -'subsystem' are literally the same before and after the rebase -'subsystem' did. +`subsystem` are literally the same before and after the rebase +`subsystem` did. In that case, the fix is easy because 'git rebase' knows to skip changes that are already present in the new upstream (unless `--reapply-cherry-picks` is given). So if you say -(assuming you're on 'topic') +(assuming you're on `topic`) ------------ $ git rebase subsystem ------------ @@ -1102,7 +1102,7 @@ you will end up with the fixed history The hard case ~~~~~~~~~~~~~ -Things get more complicated if the 'subsystem' changes do not exactly +Things get more complicated if the `subsystem` changes do not exactly correspond to the ones before the rebase. NOTE: While an "easy case recovery" sometimes appears to be successful @@ -1110,26 +1110,26 @@ NOTE: While an "easy case recovery" sometimes appears to be successful example, a commit that was removed via `git rebase --interactive` will be **resurrected**! -The idea is to manually tell 'git rebase' "where the old 'subsystem' -ended and your 'topic' began", that is, what the old merge base +The idea is to manually tell 'git rebase' "where the old `subsystem` +ended and your `topic` began", that is, what the old merge base between them was. You will have to find a way to name the last commit -of the old 'subsystem', for example: +of the old `subsystem`, for example: -* With the 'subsystem' reflog: after 'git fetch', the old tip of - 'subsystem' is at `subsystem@{1}`. Subsequent fetches will +* With the `subsystem` reflog: after 'git fetch', the old tip of + `subsystem` is at `subsystem@{1}`. Subsequent fetches will increase the number. (See linkgit:git-reflog[1].) -* Relative to the tip of 'topic': knowing that your 'topic' has three - commits, the old tip of 'subsystem' must be `topic~3`. +* Relative to the tip of `topic`: knowing that your `topic` has three + commits, the old tip of `subsystem` must be `topic~3`. -You can then transplant the old `subsystem..topic` to the new tip by -saying (for the reflog case, and assuming you are on 'topic' already): +You can then transplant the old `subsystem`..`topic` to the new tip by +saying (for the reflog case, and assuming you are on `topic` already): ------------ $ git rebase --onto subsystem subsystem@{1} ------------ The ripple effect of a "hard case" recovery is especially bad: -'everyone' downstream from 'topic' will now have to perform a "hard +'everyone' downstream from `topic` will now have to perform a "hard case" recovery too! REBASING MERGES @@ -1193,7 +1193,7 @@ merge -C 6f5e4d report-a-bug # Merge 'report-a-bug' In contrast to a regular interactive rebase, there are `label`, `reset` and `merge` commands in addition to `pick` ones. -The `label` command associates a label with the current HEAD when that +The `label` command associates a label with the current `HEAD` when that command is executed. These labels are created as worktree-local refs (`refs/rewritten/