- 02 4月, 2019 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
<branch> can be omitted in this syntax, and it's actually documented a few paragraphs down: You could omit <branch>, in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for the current branch. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
It's easier to search for and also less cryptic. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 2月, 2019 1 次提交
-
-
由 Yoichi Nakayama 提交于
Signed-off-by: NYoichi Nakayama <yoichi.nakayama@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 1月, 2019 1 次提交
-
-
由 Jean-Noël Avila 提交于
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: NJean-Noël Avila <jn.avila@free.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 1月, 2019 1 次提交
-
-
由 Thomas Gummerer 提交于
Currently 'git checkout' is defined as an overlay operation, which means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an entry in the index that matches <pathspec>, but that doesn't exist in <tree-ish>, that entry will not be removed from the index or the working tree. Introduce a new --{,no-}overlay option, which allows using 'git checkout' in non-overlay mode, thus removing files from the working tree if they do not exist in <tree-ish> but match <pathspec>. Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works this way, so no changes are needed for the patch mode. We disallow 'git checkout --overlay -p' to avoid confusing users who would expect to be able to force overlay mode in 'git checkout -p' this way. Untracked files are not affected by this change, so 'git checkout --no-overlay HEAD -- untracked' will not remove untracked from the working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/' doesn't delete all untracked files in dir/, but rather just resets the state of files that are known to git. Suggested-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 11月, 2018 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] 70c9ac2f (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] a047fafc (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 10月, 2018 1 次提交
-
-
由 Andreas Heiduk 提交于
Followup to 5dd05ebf ("doc: fix merge-base ASCII art tab spacing", 2016-10-21) Signed-off-by: NAndreas Heiduk <asheiduk@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 6月, 2018 1 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Introduce a checkout.defaultRemote setting which can be used to designate a remote to prefer (via checkout.defaultRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to use this workflow to checkout a repository and create a topic branch, then get back to a "master" as retrieved from upstream: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git checkout master ) That will output: Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' But as soon as a new remote is added (e.g. just to inspect something from someone else) the DWIMery goes away: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git remote add avar git@github.com:avar/tbdiff.git && git fetch avar && git checkout master ) Will output (without the advice output added earlier in this series): error: pathspec 'master' did not match any file(s) known to git. The new checkout.defaultRemote config allows me to say that whenever that ambiguity comes up I'd like to prefer "origin", and it'll still work as though the only remote I had was "origin". Also adjust the advice.checkoutAmbiguousRemoteBranchName message to mention this new config setting to the user, the full output on my git.git is now (the last paragraph is new): $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> hint: hint: If you'd like to always have checkouts of an ambiguous <name> prefer hint: one remote, e.g. the 'origin' remote, consider setting hint: checkout.defaultRemote=origin in your config. I considered splitting this into checkout.defaultRemote and worktree.defaultRemote, but it's probably less confusing to break our own rules that anything shared between config should live in core.* than have two config settings, and I couldn't come up with a short name under core.* that made sense (core.defaultRemoteForCheckout?). See also 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature to begin with, and 4e853331 ("worktree: make add <path> <branch> dwim", 2017-11-26) which added it to git-worktree. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 11月, 2017 1 次提交
-
-
由 Kaartic Sivaraam 提交于
@{-N} is a syntax for the N-th last "checkout" and not the N-th last "branch". Therefore, in some cases using `git checkout @{-$N}` DOES lead to a "detached HEAD" state. This can also be ensured by the commit message of 75d6e552 (Documentation: @{-N} can refer to a commit, 2014-01-19) which clearly specifies how @{-N} can be used to refer not only to a branch but also to a commit. Correct the misleading sentence which states that @{-N} doesn't detach HEAD. Signed-off-by: NKaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 10月, 2017 1 次提交
-
-
由 Junio C Hamano 提交于
There are "git checkout [-p][<tree-ish>][--][<paths>...]" in the SYNOPSIS section, and "git checkout [-p][<tree-ish>][--]<paths>..." as the header for the section that explains the "check out paths from index/tree-ish" mode. It is unclear if we require at least one path, or it is entirely optional. Actually, both are wrong. Without the "-p(atch)" option, you must have <pathspec> (otherwise, with a commit that is a <tree-ish>, you would be checking out that commit to build a new history on top of it). With it, it is already clear that you are checking out paths, it is optional. In other words, you cannot omit both. The source of the confusion is that -p(atch) is described as if it is just another "optional" part and its description is lumped together with the non patch mode, even though the actual end user experience is vastly different. Let's split the entry into two, and describe the regular mode and the patch mode separately. This allows us to make it clear that the regular mode MUST be given at least one pathspec, that the patch mode can be invoked with either '-p' or '--patch' but one of these must be given, and that the pathspec is entirely optional in the patch mode. Also, revamp the explanation of "checkout paths" by removing extraneous description at the beginning, that says "checking out paths is not checking out a branch". Explaining what it is for and when the user wants to use it upfront is the most direct way to help the readers. Noticed-by: Robert P J Day Helped-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 9月, 2017 1 次提交
-
-
由 Evan Zacks 提交于
Following are several fixes for duplicated words ("of of") and one case where an extra article ("a") slipped in. Signed-off-by: NEvan Zacks <zackse@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 7月, 2017 1 次提交
-
-
由 Stefan Beller 提交于
Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 3月, 2017 1 次提交
-
-
由 Stefan Beller 提交于
This exposes a flag to recurse into submodules in builtin/checkout making use of the code implemented in prior patches. A new failure mode is introduced in the submodule update library, as the directory/submodule conflict is not solved in prior patches. Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 9月, 2016 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Normally we err on the safe side: if something can be seen as both an SHA1 and a pathspec, we stop and scream. In checkout, there is one exception added in 859fdaba (git-checkout: improve error messages, detect ambiguities. - 2008-07-23), to allow the common case "git checkout branch". Let's document this exception. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 6月, 2016 1 次提交
-
-
由 Matthieu Moy 提交于
It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 11月, 2015 1 次提交
-
-
由 Edmundo Carmona Antoranz 提交于
Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: NEdmundo Carmona Antoranz <eantoranz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2015 2 次提交
-
-
由 Junio C Hamano 提交于
This reverts commit 0d1a1517. When trying to switch to a different branch, that happens to be checked out in another working tree, the user shouldn't have to give up the other safety measures (like protecting the local changes that overlap the difference between the branches) while defeating the "no two checkouts of the same branch" safety. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Simon A. Eugster 提交于
During a 'rebase' (hence 'pull --rebase'), --ours/--theirs may appear to be swapped to those who are not aware of the fact that they are temporarily playing the role of the keeper of the more authoritative history. Add a note to clarify. Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NSimon A. Eugster <simon.eugster@eps.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 7月, 2015 1 次提交
-
-
由 Eric Sunshine 提交于
As a safeguard, checking out a branch already checked out by a different worktree is disallowed. This behavior can be overridden with --ignore-other-worktrees, however, this option is neither obvious nor particularly discoverable. As a common safeguard override, --force is more likely to come to mind. Therefore, overload it to also suppress the check for a branch already checked out elsewhere. Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 7月, 2015 3 次提交
-
-
由 Eric Sunshine 提交于
Now that "git worktree add" has achieved user-facing feature-parity with "git checkout --to", retire the latter. Move the actual linked worktree creation functionality, prepare_linked_checkout() and its helpers, verbatim from checkout.c to worktree.c. This effectively reverts changes to checkout.c by 529fef20 (checkout: support checking out into a new working directory, 2014-11-30) with the exception of merge_working_tree() and switch_branches() which still require specialized knowledge that a the checkout is occurring in a newly-created linked worktree (signaled to them by the private GIT_CHECKOUT_NEW_WORKTREE environment variable). Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Eric Sunshine 提交于
Now that the git-worktree command exists, its documentation page is the natural place for the linked worktree description to reside. Relocate the "MULTIPLE WORKING TREES" description verbatim from git-checkout.txt to git-worktree.txt. Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Eric Sunshine 提交于
This was missed when "git prune --worktrees" became "git worktree prune". Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 6月, 2015 1 次提交
-
-
由 Torsten Bögershausen 提交于
git checkout <pathspec> can be used to reset changes in the working tree. Signed-off-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 3月, 2015 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2015 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
The goal seems to be using multiple checkouts to reduce disk space. But we have not reached an agreement how things should be. There are a couple options. - You may want to keep $SUB repos elsewhere (perhaps in a central place) outside $SUPER. This is also true for nested submodules where a superproject may be a submodule of another superproject. - You may want to keep all $SUB repos in $SUPER/modules (or some other place in $SUPER) - We could even push it further and merge all $SUB repos into $SUPER instead of storing them separately. But that would at least require ref namespace enabled. On top of that, git-submodule.sh expects $GIT_DIR/config to be per-worktree, at least for the submodule.* part. Here I think we have two options, either update config.c to also read $GIT_DIR/config.worktree (which is per worktree) in addition to $GIT_DIR/config (shared) and store worktree-specific vars in the new place, or update git-submodule.sh to read/write submodule.* directly from $GIT_DIR/config.submodule (per worktree). These take time to address properly. Meanwhile, make a note to the user that they should not use multiple worktrees in submodule context. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Noticed-by: NMark Levedahl <mlevedahl@gmail.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2014 3 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Helped-by: NMarc Branchaud <marcnarc@xiplink.com> Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
(alias R=$GIT_COMMON_DIR/worktrees/<id>) - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. - linked checkouts are supposed to update mtime of $R/gitdir. If $R/gitdir's mtime is older than a limit, and it points to nowhere, worktrees/<id> is to be pruned. - If $R/locked exists, worktrees/<id> is not supposed to be pruned. If $R/locked exists and $R/gitdir's mtime is older than a really long limit, warn about old unused repo. - "git checkout --to" is supposed to make a hard link named $R/link pointing to the .git file on supported file systems to help detect the user manually deleting the checkout. If $R/link exists and its link count is greated than 1, the repo is kept. Helped-by: NMarc Branchaud <marcnarc@xiplink.com> Helped-by: NEric Sunshine <sunshine@sunshineco.com> Helped-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
"git checkout --to" sets up a new working directory with a .git file pointing to $GIT_DIR/worktrees/<id>. It then executes "git checkout" again on the new worktree with the same arguments except "--to" is taken out. The second checkout execution, which is not contaminated with any info from the current repository, will actually check out and everything that normal "git checkout" does. Helped-by: NMarc Branchaud <marcnarc@xiplink.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2014 1 次提交
-
-
由 Thomas Rast 提交于
The @{-N} syntax always referred to the N-th last thing checked out, which can be either a branch or a commit (for detached HEAD cases). However, the documentation only mentioned branches. Edit in a "/commit" in the appropriate places. Reported-by: NKevin <ikke@ikke.info> Signed-off-by: NThomas Rast <tr@thomasrast.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 9月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
In the synopsis, the second form to detach HEAD at the named commit labelled the argument as '<commit>'. While this is technically more correct, because the feature to detach is not limited to the tip of a named branch, it was found confusing and did not express the fact that you have to give `--detach` if you are naming the commit you want to detach HEAD at with a branch name. Separate this case into two syntactical forms, mimicking the way how the DESCRIPTION section shows this usage. Also update the text that explains the syntax to name the commit to detach HEAD at to clarify. Suggested-by: NBenjamin Bergman <ben@benbergman.ca> Helped-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 4月, 2013 1 次提交
-
-
由 Johan Herland 提交于
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: NJohan Herland <johan@herland.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 4月, 2013 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
"git checkout -- <paths>" is usually used to restore all modified files in <paths>. In sparse checkout mode, this command is overloaded with another meaning: to add back all files in <paths> that are excluded by sparse patterns. As the former makes more sense for day-to-day use. Switch it to the default and the latter enabled with --ignore-skip-worktree-bits. While at there, add info/sparse-checkout to gitrepository-layout.txt Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 2月, 2013 1 次提交
-
-
由 Thomas Ackermann 提交于
Signed-off-by: NThomas Ackermann <th.acker@arcor.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 12月, 2012 2 次提交
-
-
由 Chris Rorvick 提交于
Document the behavior implemented in 70c9ac2f (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"). Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Chris Rorvick 提交于
The forms of checkout that do not take a path are lumped together in the DESCRIPTION section, but the description for this group is dominated by explanation of the -b|-B form. Split these apart for more clarity. Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 9月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
Just like we give a similar example in "git add" documentation. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 8月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
While the synopsis section makes it clear that the new branch name is the parameter to these flags, the option description did not. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 4月, 2012 1 次提交
-
-
由 Jeff King 提交于
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 5月, 2011 1 次提交
-
-
由 Valentin Haenel 提交于
Describe '-p' as a short form of '--patch' in synopsis and options. Also refer the reader to the patch mode description of git-add documentation. Helped-by: NJeff King <peff@peff.net> Mentored-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NValentin Haenel <valentin.haenel@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-