summaryrefslogtreecommitdiff
path: root/Documentation/gitcore-tutorial.txt
AgeCommit message (Collapse)AuthorFilesLines
2015-06-05Merge branch 'ja/tutorial-asciidoctor-fix' into maintLibravatar 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>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-51/+51
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-07-01Documentation: fix links to tutorials and other new manual pagesLibravatar Jonathan Nieder1-5/+4
With the conversion of HTML documentation to man pages tutorial.html -> gittutorial (7) tutorial-2.html -> gittutorial-2 (7) cvs-migration.html -> gitcvs-migration (7) diffcore.html -> gitdiffcore (7) repository-layout.html -> gitrepository-layout (5) hooks.html -> githooks (5) glossary.html -> gitglossary (7) core-tutorial.html -> gitcore-tutorial (7) and the automatic update of references to these pages, a little debris was left behind. We clear it away. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06documentation: convert "diffcore" and "repository-layout" to man pagesLibravatar Christian Couder1-1/+1
This patch renames the following documents and at the same time converts them to the man format: diffcore.txt -> gitdiffcore.txt (man section 7) repository-layout.txt -> gitrepository-layout.txt (man section 5) Other documents that reference the above ones are changed accordingly. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-01Documentation: convert "glossary" and "core-tutorial" to man pagesLibravatar Christian Couder1-0/+1699
This patch renames the following documents and at the same time converts them to the man format: core-tutorial.txt -> gitcore-tutorial.txt glossary.txt -> gitglossary.txt But as the glossary is included in the user manual and as the new gitglossary man page cannot be included as a whole in the user manual, the actual glossary content is now in its own "glossary-content.txt" new file. And this file is included by both the user manual and the gitglossary man page. Other documents that reference the above ones are changed accordingly and sometimes improved a little too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>