summaryrefslogtreecommitdiff
path: root/Documentation/gitcore-tutorial.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-04-20gitcore-tutorial: update broken linkLibravatar Jeff King1-1/+1
The slides for the Linux-mentoring presentation are no longer available. Let's point to the wayback version of the page, which works. Note that the referenced diagram is also available on page 15 of [1]. We could link to that instead, but it's not clear from the URL scheme ("uploads") whether it's going to stick around forever. [1] https://www.linuxfoundation.jp/jp_uploads/seminar20070313/Randy.pdf Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-15Merge branch 'sb/doc-unify-bottom'Libravatar Junio C Hamano1-1/+1
Doc clean-up. * sb/doc-unify-bottom: Documentation: unify bottom "part of git suite" lines
2017-02-09Documentation: unify bottom "part of git suite" linesLibravatar Stefan Beller1-1/+1
We currently have 168 man pages that mention they are part of Git, you can check yourself easily via: $ git grep "Part of the linkgit:git\[1\] suite" |wc -l 168 However some have a trailing period, i.e. $ git grep "Part of the linkgit:git\[1\] suite." |wc -l 8 Unify the bottom line in all man pages to not end with a period. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09doc: omit needless "for"Libravatar Kristoffer Haugsbakk1-1/+1
What was intended was perhaps "... plumbing does for you" ("you" added), but simply omitting the word "for" is more terse and gets the intended point across just as well, if not more so. I originally went with the approach of writing "for you", but Junio C Hamano suggested this approach instead. Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09doc: make the intent of sentence clearerLibravatar Kristoffer Haugsbakk1-1/+1
By adding the word "just", which might have been accidentally omitted. Adding the word "just" makes it clear that the point is to *not* do an octopus merge simply because you *can* do it. In other words, you should have a reason for doing it beyond simply having two (seemingly) independent commits that you need to merge into another branch, since it's not always the best approach. The previous sentence made it look more like it was trying to say that you shouldn't do an octopus merge *because* you can do an octopus merge. Although this interpretation doesn't make sense and the rest of the paragraph makes the intended meaning clear, this adjustment should make the intent of the sentence more immediately clear to the reader. Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09doc: add verb in front of command to runLibravatar Kristoffer Haugsbakk1-1/+1
Instead of using the command 'git clone' as a verb, use "run" as the verb indicating the action of executing the command 'git clone'. Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09doc: add articles (grammar)Libravatar Kristoffer Haugsbakk1-3/+3
Add definite and indefinite articles in three places where they were missing. - Use "the" in front of a directory name - Use "the" in front of "style of cooperation" - Use an indefinite article in front of "CVS background" Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-1/+1
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01transport: drop support for git-over-rsyncLibravatar Jeff King1-16/+2
The git-over-rsync protocol is inefficient and broken, and has been for a long time. It transfers way more objects than it needs (grabbing all of the remote's "objects/", regardless of which objects we need). It does its own ad-hoc parsing of loose and packed refs from the remote, but doesn't properly override packed refs with loose ones, leading to garbage results (e.g., expecting the other side to have an object pointed to by a stale packed-refs entry, or complaining that the other side has two copies of the refs[1]). This latter breakage means that nobody could have successfully pulled from a moderately active repository since cd547b4 (fetch/push: readd rsync support, 2007-10-01). We never made an official deprecation notice in the release notes for git's rsync protocol, but the tutorial has marked it as such since 914328a (Update tutorial., 2005-08-30). And on the mailing list as far back as Oct 2005, we can find Junio mentioning it as having "been deprecated for quite some time."[2,3,4]. So it was old news then; cogito had deprecated the transport in July of 2005[5] (though it did come back briefly when Linus broke git-http-pull!). Of course some people professed their love of rsync through 2006, but Linus clarified in his usual gentle manner[6]: > Thanks! This is why I still use rsync, even though > everybody and their mother tells me "Linus says rsync is > deprecated." No. You're using rsync because you're actively doing something _wrong_. The deprecation sentiment was reinforced in 2008, with a mention that cloning via rsync is broken (with no fix)[7]. Even the commit porting rsync over to C from shell (cd547b4) lists it as deprecated! So between the 10 years of informal warnings, and the fact that it has been severely broken since 2007, it's probably safe to simply remove it without further deprecation warnings. [1] http://article.gmane.org/gmane.comp.version-control.git/285101 [2] http://article.gmane.org/gmane.comp.version-control.git/10093 [3] http://article.gmane.org/gmane.comp.version-control.git/17734 [4] http://article.gmane.org/gmane.comp.version-control.git/18911 [5] http://article.gmane.org/gmane.comp.version-control.git/5617 [6] http://article.gmane.org/gmane.comp.version-control.git/19354 [7] http://article.gmane.org/gmane.comp.version-control.git/103635 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'ja/tutorial-asciidoctor-fix'Libravatar Junio C Hamano1-1/+1
A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * ja/tutorial-asciidoctor-fix: doc: fix unmatched code fences
2015-05-12doc: fix unmatched code fencesLibravatar Jean-Noel Avila1-1/+1
This mismatch upsets the renderer on git-scm.com. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-10doc: add 'everyday' to 'git help'Libravatar Philip Oakley1-1/+1
The "Everyday GIT With 20 Commands Or So" is not accessible via the Git help system. Move everyday.txt to giteveryday.txt so that "git help everyday" works, and create a new placeholder file everyday.html to refer people who follow existing URLs to the updated location. giteveryday.txt now formats well with AsciiDoc as a man page and refreshed content to a more command modern style. Add 'everyday' to the help --guides list and update git(1) and 5 other links to giteveryday. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-20Documentation: fix documentation AsciiDoc links for external urlsLibravatar Roberto Tyley1-1/+1
Turns out that putting 'link:' before the 'http' is actually superfluous in AsciiDoc, as there's already a predefined macro to handle it. "http, https, [etc] URLs are rendered using predefined inline macros." http://www.methods.co.nz/asciidoc/userguide.html#_urls "Hypertext links to files on the local file system are specified using the link inline macro." http://www.methods.co.nz/asciidoc/userguide.html#_linking_to_local_documents Despite being superfluous, the reference implementation of AsciiDoc tolerates the extra 'link:' and silently removes it, giving a functioning link in the generated HTML. However, AsciiDoctor (the Ruby implementation of AsciiDoc used to render the http://git-scm.com/ site) does /not/ have this behaviour, and so generates broken links, as can be seen here: http://git-scm.com/docs/git-cvsimport (links to cvs2git & parsecvs) http://git-scm.com/docs/git-filter-branch (link to The BFG) It's worth noting that after this change, the html generated by 'make html' in the git project is identical, and all links still work. Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-13core-tutorial: trim the section on Inspecting ChangesLibravatar Junio C Hamano1-36/+3
Back when the core tutorial was written, `log` and `whatchanged` were scripted Porcelains. In the "Inspecting Changes" section that talks about the plumbing commands in the diff family, it made sense to use `log` and `whatchanged` as good examples of the use of these plumbing commands, and because even these scripted Porcelains were novelty (there wasn't the new end-user tutorial written), it made some sense to illustrate uses of the `git log` (and `git whatchanged`) scripted Porcelain commands. But we no longer have scripted `log` and `whatchanged` to serve as examples, and this document is not where the end users learn what `git log` command is about. Stop at briefly mentioning the possibility of combining rev-list with diff-tree to build your own log, and leave the end-user documentation of `log` to the new tutorial and the user manual. Also resurrect the last version of `git-log`, `git-whatchanged`, and `git-show` to serve as examples to contrib/examples/ directory. While at it, remove 'whatchanged' from a list of sample commands that are affected by GIT_FLUSH environment variable. This is not meant to be an exhaustive list but as a list of typical ones, and an old command that is kept primarily for backward compatibility does not belong to it. Helped-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Libravatar Thomas Ackermann1-4/+4
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-75/+75
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: avoid poor-man's small caps GITLibravatar Thomas Ackermann1-2/+2
In the earlier days, we used to spell the name of the system as GIT, to simulate as if it were typeset with capital G and IT in small caps. Later we stopped doing so at around 1.6.5 days. Let's stop doing so throughout the documentation. The name to refer to the whole system (and the concept it embodies) is "Git"; the command end-users type is "git". And document this in the coding guideline. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-13Documentation: describe subject more preciselyLibravatar Jeremy White1-5/+4
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. This patch refines that, and makes more use of the concept of a commit title, with the title being all text up to the first blank line. Signed-off-by: Jeremy White <jwhite@codeweavers.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'zj/diff-stat-smaller-num-columns'Libravatar Junio C Hamano1-2/+2
Spend only minimum number of columns necessary to show the number of lines in the output from "diff --stat", instead of always allocating 4 columns even when showing changes that are much smaller than 1000 lines. By Zbigniew Jędrzejewski-Szmek * zj/diff-stat-smaller-num-columns: diff --stat: use less columns for change counts
2012-04-30diff --stat: use less columns for change countsLibravatar Zbigniew Jędrzejewski-Szmek1-2/+2
Number of columns required for change counts is now computed based on the maximum number of changed lines instead of being fixed. This means that usually a few more columns will be available for the filenames and the graph. The graph width logic is also modified to include enough space for "Bin XXX -> YYY bytes". If changes to binary files are mixed with changes to text files, change counts are padded to take at least three columns. And the other way around, if change counts require more than three columns, then "Bin"s are padded to align with the change count. This way, the +- part starts in the same column as "XXX -> YYY" part for binary files. This makes the graph easier to parse visually thanks to the empty column. This mimics the layout of diff --stat before this change. Tests and the tutorial are updated to reflect the new --stat output. This means either the removal of extra padding and/or the addition of up to three extra characters to truncated filenames. One test is added to check the graph alignment when a binary file change and text file change of more than 999 lines are committed together. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-14/+14
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>
2012-02-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-1/+1
"git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13Documentation: gitrevisions is in section 7Libravatar Jonathan Nieder1-1/+1
Fix references to gitrevisions(1) in the manual pages and HTML documentation. In practice, this will not matter much unless someone tries to use a hard copy of the git reference manual. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: avoid stray backslashes in core tutorialLibravatar Jonathan Nieder1-9/+9
While at it: - remove some single-quotes that were being rendered as ’\n\'; - do not escape ellipses (...) when they do not represent the literal three characters "...". We may want to ensure the manpages render these as three ASCII periods to make the manual pages easier to search, but that would be a global output generation setting, not a context-specific thing; Reported-by: Frédéric Brière <fbriere@fbriere.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Documentation: link to gitrevisions rather than git-rev-parseLibravatar Michael J Gruber1-1/+1
Currently, whenever we need documentation for revisions and ranges, we link to the git-rev-parse man page, i.e. a plumbing man page, which has this along with the documentation of all rev-parse modes. Link to the new gitrevisions man page instead in all cases except - when the actual git-rev-parse command is referred to or - in very technical context (git-send-pack). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-80/+80
* remotes/trast-doc/for-next: Documentation: spell 'git cmd' without dash throughout Documentation: format full commands in typewriter font Documentation: warn prominently against merging with dirty trees Documentation/git-merge: reword references to "remote" and "pull" Conflicts: Documentation/config.txt Documentation/git-config.txt Documentation/git-merge.txt
2010-01-16Documentation: Update git core tutorial clarifying reference to scriptsLibravatar Ramkumar Ramachandra1-0/+8
Back when the git core tutorial was written, porcelain commands were shell scripts. This patch adds a paragraph explaining this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-80/+80
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.
2009-12-01Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: help: Do not unnecessarily look for a repository Documentation: Fix a few i.e./e.g. mix-ups Documentation: Document --branch option in git clone synopsis
2009-12-01Documentation: Fix a few i.e./e.g. mix-upsLibravatar Michael J Gruber1-1/+1
A git bundle can be transported by several means (such as e-mail), not only by snekaernet, so use e.g. instead of i.e. The mix-up in git-bundle.txt is obvious. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-25t1200: fix a timing dependent errorLibravatar Nanako Shiraishi1-2/+2
The fourth test of show-branch in t1200 test was failing but only sometimes. It only failed when two commits created in an earlier test had different timestamps. When they were created within the same second, the actual output matched the expected output. Fix this by using test_tick to force reliable timestamps and update the expected output so it does not to depend on the commits made in the same sacond. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-17Merge branch 'sb/tutorial-test'Libravatar Junio C Hamano1-10/+10
* sb/tutorial-test: t1200: prepare for merging with Fast-forward bikeshedding t1200: further modernize test script style t1200: Make documentation and test agree t1200: cleanup and modernize test style
2009-11-06t1200: Make documentation and test agreeLibravatar Stephen Boyd1-10/+10
There were some differences between t1200 and the gitcore-tutorial. Add missing tests for manually merging two branches, and use the same commands in both files. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-2/+2
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Change mentions of "git programs" to "git commands"Libravatar Ori Avtalion1-2/+2
Most of the docs and printouts refer to "commands" when discussing what the end users call via the "git" top-level program. We should refer them as "git programs" when we discuss the fact that the commands are implemented as separate programs, but in other contexts, it is better to use the term "git commands" consistently. Signed-off-by: Ori Avtalion <ori@avtalion.name> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-13Fix Documentation typos surrounding the word 'handful'.Libravatar Jon Loeliger1-4/+4
Some instances replaced by "handful of", others use the word "few", a couple get a slight rewording. Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Merge branch 'maint' to sync with GIT 1.6.0.6Libravatar Junio C Hamano1-4/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Documentation: fix typos, grammar, asciidoc syntaxLibravatar Markus Heidelberg1-4/+4
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Documentation: sync example output with git outputLibravatar Markus Heidelberg1-6/+5
Don't confuse the user with old git messages. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-17Documentation: tutorial: add information about "git help" at the beginningLibravatar Christian Couder1-0/+1
Talking about "git help" is useful because it has a few more features (like when using it without arguments or with "-a") and it may work on non unix like platforms. Also add a few links to git-help(1) in "See also" sections. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14Documentation: fix links to "everyday.html"Libravatar Christian Couder1-2/+4
In some places the links are wrong. They should be: "link:everyday.html", instead of: "linkgit:everyday[7]". This patch fixes that. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-11Adjust for the new way of enabling the default post-update hookLibravatar Petr Baudis1-7/+8
The post-update hook, which is required to be enabled in order for the repository to be accessible over HTTP, is not enabled by chmod a+x anymore, but instead by dropping the .sample suffix. This patch emphasizes this change in the release notes (since I believe this is rather noticeable backwards-incompatible change). It also adjusts the documentation which still described the old way and fixes t/t5540-http-push.sh, which was broken for 1.5 month but apparently noone ever runs this test. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08Documentation: fix broken "linkgit" linksLibravatar Eric Hanchrow1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: use teletype font for sample command linesLibravatar Jonathan Nieder1-1/+1
I think that some of these uses of italics were meant to be rendered in quotation marks, anyway. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git subcommand names (which were in teletype font)Libravatar Jonathan Nieder1-3/+3
Italicize those git subcommand names already in teletype we missed. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize nongit command names (if they are in teletype font)Libravatar Jonathan Nieder1-7/+7
Some manual pages use teletype font to set command names. We change them to use italics, instead. This creates a visual distinction between names of commands and command lines that can be typed at the command line. It is also more consistent with other man pages outside Git. In this patch, the commands named are non-git commands like bash. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize gitk's name (where it was in teletype font)Libravatar Jonathan Nieder1-1/+1
The name `gitk` is sometimes meant to be entered at the command prompt, but most uses are just referring to the program with that name (not the incantation to start it). Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-81/+81
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-05Documentation: more "git-" versus "git " changesLibravatar Jonathan Nieder1-15/+15
With git-commands moving out of $(bindir), it is useful to make a clearer distinction between the git subcommand 'git-whatever' and the command you type, `git whatever <options>`. So we use a dash after "git" when referring to the former and not the latter. I already sent a patch doing this same thing, but I missed some spots. 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-9/+9
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>