summaryrefslogtreecommitdiff
path: root/Documentation/git-pull.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-05-01doc: git-pull.txt use US spelling, fix minor typoLibravatar René Genz1-2/+3
Signed-off-by: René Genz <liebundartig@freenet.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10Merge branch 'mm/push-social-engineering-attack-doc'Libravatar Junio C Hamano1-0/+2
Doc update on fetching and pushing. * mm/push-social-engineering-attack-doc: doc: mention transfer data leaks in more places
2016-11-14doc: mention transfer data leaks in more placesLibravatar Matt McCutchen1-0/+2
The "SECURITY" section of the gitnamespaces(7) man page described two ways for a client to steal data from a server that wasn't intended to be shared. Similar attacks can be performed by a server on a client, so adapt the section to cover both directions and add it to the git-fetch(1), git-pull(1), and git-push(1) man pages. Also add references to this section from the documentation of server configuration options that attempt to control data leakage but may not be fully effective. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-21pull --rebase: add --[no-]autostash flagLibravatar Mehul Jain1-0/+9
If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the --[no-]autostash option, it's just a matter of passing the option to underlying "git rebase" when "git pull --rebase" is called. Helped-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Paul Tan <pyokagan@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13pull: allow interactive rebase with --rebase=interactiveLibravatar Johannes Schindelin1-1/+3
A couple of years ago, I found the need to collaborate on topic branches that were rebased all the time, and I really needed to see what I was rebasing when pulling, so I introduced an interactively-rebasing pull. The way builtin pull works, this change also supports the value 'interactive' for the 'branch.<name>.rebase' config variable, which is a neat thing because users can now configure given branches for interactively-rebasing pulls without having to type out the complete `--rebase=interactive` option every time they pull. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-02pull: handle git-fetch's options as wellLibravatar Paul Tan1-3/+0
While parsing the command-line arguments, git-pull stops parsing at the first unrecognized option, assuming that any subsequent options are for git-fetch, and can thus be kept in the shell's positional parameters list, so that it can be passed to git-fetch via the expansion of "$@". However, certain functions in git-pull assume that the positional parameters do not contain any options: * error_on_no_merge_candidates() uses the number of positional parameters to determine which error message to print out, and will thus print the wrong message if git-fetch's options are passed in as well. * the call to get_remote_merge_branch() assumes that the positional parameters only contains the optional repo and refspecs, and will thus silently fail if git-fetch's options are passed in as well. * --dry-run is a valid git-fetch option, but if provided after any git-fetch options, it is not recognized by git-pull and thus git-pull will continue to run the merge or rebase. Fix these bugs by teaching git-pull to parse git-fetch's options as well. Add tests to prevent regressions. This removes the limitation where git-fetch's options have to come after git-merge's and git-rebase's options on the command line. Update the documentation to reflect this. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-28Merge branch 'ss/pull-rebase-preserve'Libravatar Junio C Hamano1-3/+2
* ss/pull-rebase-preserve: docs: clarify "preserve" option wording for git-pull
2015-03-26docs: clarify "preserve" option wording for git-pullLibravatar Sebastian Schuberth1-3/+2
The "also" sounds as if "preserve" does a rebase as an additional step that "true" would not do, but that is not the case. Clarify this by omitting "also", and rewording the sentence a bit. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'jc/maint-pull-docfix'Libravatar Junio C Hamano1-2/+2
* jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull"
2014-01-14Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfixLibravatar Junio C Hamano1-2/+2
* jc/maint-pull-docfix-for-409b8d82: Documentation: exclude irrelevant options from "git pull"
2014-01-14Documentation: exclude irrelevant options from "git pull"Libravatar Junio C Hamano1-2/+2
10eb64f5 (git pull manpage: don't include -n from fetch-options.txt, 2008-01-25) introduced a way to exclude some parts of included source when building git-pull documentation, and later 409b8d82 (Documentation/git-pull: put verbosity options before merge/fetch ones, 2010-02-24) attempted to use the mechanism to exclude some parts of merge-options.txt when used from git-pull.txt. However, the latter did not have an intended effect, because the macro "git-pull" used to decide if the source is included in git-pull documentation were defined a bit too late. Define the macro before it is used to fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31doc/pull: clarify the illustrationsLibravatar Junio C Hamano1-1/+3
The second illustration that shows the history after "git pull" spelled the remote-tracking branch with "remotes/" prefix, which is not necessary. Drop it. To match the assumption that a remote-tracking branch is used to keep track of the advancement of the master at the origin, update the first illustration that shows the history before "git pull" to show the distinction between the master currently at origin and the stale origin/master remote-tracking branch. Noticed-by: Felipe Contreras <felipe.contreras@gmail.com> Helped-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04pull: allow pull to preserve merges when rebasingLibravatar Stephen Haberman1-6/+12
If a user is working on master, and has merged in their feature branch, but now has to "git pull" because master moved, with pull.rebase their feature branch will be flattened into master. This is because "git pull" currently does not know about rebase's preserve merges flag, which would avoid this behavior, as it would instead replay just the merge commit of the feature branch onto the new master, and not replay each individual commit in the feature branch. Add a --rebase=preserve option, which will pass along --preserve-merges to rebase. Also add 'preserve' to the allowed values for the pull.rebase config setting. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-08pull: change the description to "integrate" changesLibravatar John Keeping1-1/+1
Since git-pull learned the --rebase option it has not just been about merging changes from a remote repository (where "merge" is in the sense of "git merge"). Change the description to use "integrate" instead of "merge" in order to reflect this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.1: merge-tree: fix typo in merge-tree.c::unresolved git-commit doc: describe use of multiple `-m` options git-pull doc: fix grammo ("conflicts" is plural)
2013-03-27git-pull doc: fix grammo ("conflicts" is plural)Libravatar Mihai Capotă1-1/+1
Signed-off-by: Mihai Capotă <mihai@mihaic.ro> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-17man: git pull -r is a short for --rebaseLibravatar Miklos Vajna1-0/+1
Letting the "--rebase" option squat on the short-and-sweet single letter option "-r" was an unintended accident and was not even documented, but the short option seems to be already used in the wild. Let's document it so that other options that begin with "r" would not be tempted to steal it. Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-1/+1
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'ab/pull-rebase-config'Libravatar Junio C Hamano1-1/+1
* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
2011-11-07pull: introduce a pull.rebase option to enable --rebaseLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Currently we either need to set branch.<name>.rebase for existing branches if we'd like "git pull" to mean "git pull --rebase", or have the forethought of setting "branch.autosetuprebase" before we create the branch. Introduce a "pull.rebase" option to globally configure "git pull" to mean "git pull --rebase" for any branch. This option will be considered at a lower priority than branch.<name>.rebase, i.e. we could set pull.rebase=true and branch.<name>.rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com> Reviewed-by: Fernando Vezzosi <buccia@repnz.net> Reviewed-by: Eric Herman <eric@freesa.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04Merge branch 'jl/submodule-fetch-on-demand'Libravatar Junio C Hamano1-1/+10
* jl/submodule-fetch-on-demand: fetch/pull: Describe --recurse-submodule restrictions in the BUGS section submodule update: Don't fetch when the submodule commit is already present fetch/pull: Don't recurse into a submodule when commits are already present Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option config: teach the fetch.recurseSubmodules option the 'on-demand' value fetch/pull: Add the 'on-demand' value to the --recurse-submodules option fetch/pull: recurse into submodules when necessary Conflicts: builtin/fetch.c submodule.c
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-12/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2011-03-09fetch/pull: Describe --recurse-submodule restrictions in the BUGS sectionLibravatar Jens Lehmann1-0/+9
Using the --recurse-submodules option with fetch and pull might not always fetch all the submodule commits the user expects, as this will only work when the submodule is already checked out. Document that and warn that this is expected to change in the future. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: Add the 'on-demand' value to the --recurse-submodules optionLibravatar Jens Lehmann1-1/+1
Until now the --recurse-submodules option could only be used to either fetch all populated submodules recursively or to disable recursion completely. As fetch and pull now by default just fetch those submodules for which new commits have been fetched in the superproject, a command line option to enforce that behavior is needed to be able to override configuration settings. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-07pull: Document the "--[no-]recurse-submodules" optionsLibravatar Jens Lehmann1-0/+9
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options "--[no-]recurse-submodules" had been added to git-pull.sh. But they were not documented as the pull options they now are, so let's fix that. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12Merge branch 'ja/maint-pull-rebase-doc'Libravatar Junio C Hamano1-2/+3
* ja/maint-pull-rebase-doc: git-pull.txt: Mention branch.autosetuprebase
2010-12-03Merge branch 'maint' to sync with Git 1.7.3.3Libravatar Junio C Hamano1-2/+2
* maint: Git 1.7.3.3 CodingGuidelines: mention whitespace preferences for shell scripts Documentation: do not misinterpret pull refspec as bold text Conflicts: Documentation/git-pull.txt RelNotes
2010-12-03Documentation: do not misinterpret pull refspec as bold textLibravatar Jonathan Nieder1-2/+2
Use the {asterisk} entity to avoid mistreating the asterisks in "(e.g., refs/heads/*:refs/remotes/origin/*)" as delimiters for bold text. From a quick search with 'git grep -e "\*.*\*"', this seems to be the last example of this particular formatting problem. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-03git-pull.txt: Mention branch.autosetuprebaseLibravatar Jari Aalto1-2/+3
In "Options related to merging" mention also related option branch.autosetuprebase in git-config(1). Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'mm/phrase-remote-tracking'Libravatar Junio C Hamano1-4/+4
* mm/phrase-remote-tracking: git-branch.txt: mention --set-upstream as a way to change upstream configuration user-manual: remote-tracking can be checked out, with detached HEAD user-manual.txt: explain better the remote(-tracking) branch terms Change incorrect "remote branch" to "remote tracking branch" in C code Change incorrect uses of "remote branch" meaning "remote-tracking" Change "tracking branch" to "remote-tracking branch" everyday.txt: change "tracking branch" to "remote-tracking branch" Change remote tracking to remote-tracking in non-trivial places Replace "remote tracking" with "remote-tracking" Better "Changed but not updated" message in git-status
2010-11-17Documentation/git-pull: clarify configurationLibravatar Martin von Zweigbergk1-6/+8
The sentence about 'branch.<name>.rebase' refers to the first sentence in the paragraph and not to the sentence about avoiding rebasing non-local changes. Clarify this. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change "tracking branch" to "remote-tracking branch"Libravatar Matthieu Moy1-3/+3
One more step towards consistancy. We change the documentation and the C code in a single patch, since the only instances in the C code are in comment and usage strings. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Replace "remote tracking" with "remote-tracking"Libravatar Matthieu Moy1-1/+1
"remote-tracking" branch makes it explicit that the branch is "tracking a remote", as opposed to "remote, and tracking something". See discussion in e.g. http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com for more details. This patch is a straightforward application of perl -pi -e 's/remote tracking branch/remote-tracking branch/' except in the RelNotes directory. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-02Documentation: flesh out “git pull” descriptionLibravatar Jonathan Nieder1-11/+54
The current description in the pull man page does not say much more than that “git pull” is fetch + merge. Though that is all a person needs to know in the end, it would be useful to summarize a bit about what those commands do for new readers. Most of this description is taken from the “git merge” docs. Now that we explain how to back out of a failed merge (reset --merge), we can tone down the warning against that a bit. Except, as Thomas noticed, there’s a risk with that because people might read this version of the manpage online and then conclude that it is safe to try a merge with uncommitted changes, only to find that their “git reset” doesn't support --merge yet. Or worse, verify that their git-reset has --merge by a quick test (1b5b465 is in 1.6.2) but then find that it does not help with backing out of a merge (e11d7b5 is only in 1.7.0!). So keep the warning. With clarifications from Ævar, Thomas, and Junio. Noticed-by: Geoff Russell <geoffrey.russell@gmail.com> Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24fetch and pull: learn --progressLibravatar Tay Ray Chuan1-1/+3
Note that in the documentation for git-pull, documentation for the --progress option is displayed under the "Options related to fetching" subtitle via fetch-options.txt. Also, update the documentation of the -q/--quiet option for git-pull to mention its effect on progress reporting during fetching. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24Documentation/git-pull: put verbosity options before merge/fetch onesLibravatar Tay Ray Chuan1-0/+8
After 3f7a9b5 (Documentation/git-pull.txt: Add subtitles above included option files, Thu Oct 22 2009), the -q/-v options were mentioned only for the merge options section, giving the impression that git-fetch did not take those arguments. Follow 90e4311 (git-pull: do not mention --quiet and --verbose twice, Mon Sep 7 2009) and hide -q/-v for merge options, while mentioning -q/-v before the merge- and fetch-specific options. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-6/+6
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2010-01-09Documentation: warn prominently against merging with dirty treesLibravatar Thomas Rast1-0/+4
We do this for both git-merge and git-pull, so as to hopefully alert (over)users of git-pull to the issue. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2009-10-30Merge branch 'ja/fetch-doc'Libravatar Junio C Hamano1-0/+7
* ja/fetch-doc: Documentation/merge-options.txt: order options in alphabetical groups Documentation/git-pull.txt: Add subtitles above included option files Documentation/fetch-options.txt: order options alphabetically
2009-10-22Documentation/git-pull.txt: Add subtitles above included option filesLibravatar Jari Aalto1-0/+7
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-21modernize fetch/merge/pull examplesLibravatar Clemens Buchacher1-45/+4
The "git pull" documentation has examples which follow an outdated style. Update the examples to use "git merge" where appropriate and move the examples to the corresponding manpages. Furthermore, - show that pull is equivalent to fetch and merge, which is still a frequently asked question, - explain the default fetch refspec. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Update my e-mail addressLibravatar Junio C Hamano1-1/+1
The old cox.net address is still getting mails from gitters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-5/+5
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-2/+1
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-12Documentation/git-pull.txt: Use more standard [NOTE] markupLibravatar Junio C Hamano1-1/+2
Unlike other manual pages (e.g. git-blame.txt), this used *NOTE:* to show a side note headed with boldface string "NOTE". Use a paragraph headed by [NOTE] like others instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-3/+3
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>