summaryrefslogtreecommitdiff
path: root/Documentation/gittutorial.txt
AgeCommit message (Collapse)AuthorFilesLines
2019-04-02doc: promote "git switch"Libravatar Nguyễn Thái Ngọc Duy1-2/+2
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23treewide: correct several "up-to-date" to "up to date"Libravatar Martin Ågren1-1/+1
Follow the Oxford style, which says to use "up-to-date" before the noun, but "up to date" after it. Don't change plumbing (specifically send-pack.c, but transport.c (git push) also has the same string). This was produced by grepping for "up-to-date" and "up to date". It turned out we only had to edit in one direction, removing the hyphens. Fix a typo in Documentation/git-diff-index.txt while we're there. Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com> Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-02-01transport: drop support for git-over-rsyncLibravatar Jeff King1-1/+1
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>
2014-11-19Merge branch 'sn/tutorial-status-output-example'Libravatar Junio C Hamano1-8/+9
* sn/tutorial-status-output-example: gittutorial: fix output of 'git status'
2014-11-13gittutorial: fix output of 'git status'Libravatar Stefan Naewe1-8/+9
'git status' doesn't output leading '#'s these days. Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-11gittutorial.txt: remove reference to ancient Git versionLibravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-10doc: add 'everyday' to 'git help'Libravatar Philip Oakley1-2/+2
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>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-22/+22
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-1/+1
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-3/+5
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>
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>
2010-11-03Change remote tracking to remote-tracking in non-trivial placesLibravatar Matthieu Moy1-2/+2
To complement the straightforward perl application in previous patch, this adds a few manual changes. 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-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-21/+21
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-06-30Makes some cleanup/review in gittutorialLibravatar Thadeu Lima de Souza Cascardo1-12/+12
There are some different but little cleanup changes to fix some missing quotes, to fix what seemed to be an unended sentence, to reident a little paragraph with too large a sentence and fix a branch name that was referred to twice later by another name. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06Documentation: refer to gitworkflows(7) from tutorial and git(1)Libravatar Thomas Rast1-0/+4
Add references to the gitworkflows(7) manpage added in f948dd8 (Documentation: add manpage about workflows, 2008-10-19) to both gittutorial(1) and git(1), so that new users might actually discover and read it. Noticed by Randal L. Schwartz. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-25gittutorial: remove misleading noteLibravatar Miklos Vajna1-3/+1
In the tutorial Alice initializes the repository, and Bob clones it. So Bob can just do a 'git pull', but Alice will need 'git pull <url> <branch>'. The note suggested that the branch parameter is not necessary, which is no longer true these days. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05Use capitalized names where appropriateLibravatar Henrik Austad1-2/+2
The Linux kernel and Emacs are both spelled capitalized Signed-off-by: Henrik Austad <henrik@austad.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-17Documentation: tutorial: add information about "git help" at the beginningLibravatar Christian Couder1-0/+10
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-08-29tutorial: gentler illustration of Alice/Bob workflow using gitkLibravatar Paolo Ciarrocchi1-1/+28
Update to gitutorial as discussedin the git mailing list: http://marc.info/?t=121969390900002&r=1&w=2 Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-14tutorial: clarify "pull" is "fetch + merge"Libravatar Junio C Hamano1-1/+27
The document says that a fetch with a configured remote stores what are fetched in the remote tracking branches "Unlike the longhand form", but there is no longhand form "fetch" demonstrated earlier. This adds a missing demonstration of the longhand form, and a new paragraph to explain why some people might want to fetch before pull. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-14tutorial: use prompt with user names in example, to clarify who is doing whatLibravatar Ian Katz1-13/+13
Signed-off-by: Ian Katz <ifreecarve@gmail.com> 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-21/+21
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-23/+23
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-15/+15
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: prepare to be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-2/+2
With the dashed forms of git commands not in $(bindir), we have to change many instances of "git-command" to "git command". Also, for consistency it is at times appropriate to make the opposite change. In some cases, the change is not so simple as changing one character. This patch gets rid of some of those cases by rewrapping lines. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: complicate example of "man git-command"Libravatar Jonathan Nieder1-2/+2
The manual page for the command invoked as "git clone" is named git-clone(1), and similarly for the rest of the git commands. Make sure our first example of this in tutorials makes it clear that it is the first two words of a command line that make up the command's name (that is: for example, the effect of "git svn dcommit" is described in git-svn(1)). 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-4/+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-11Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: fix typo in tutorial
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-01Documentation: convert "glossary" and "core-tutorial" to man pagesLibravatar Christian Couder1-0/+2
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>
2008-05-24Documentation: convert tutorials to man pagesLibravatar Christian Couder1-0/+606
This patch renames the following documents and at the same time converts them to the man page format: cvs-migration.txt -> gitcvs-migration.txt tutorial.txt -> gittutorial.txt tutorial-2.txt -> gittutorial-2.txt These new man pages are put in section 7, and other documents that reference the above ones are change accordingly. [jc: with help from Nanako to clean things up] Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>