summaryrefslogtreecommitdiff
path: root/Documentation/git-add.txt
AgeCommit message (Collapse)AuthorFilesLines
2011-05-11Merge branch 'vh/config-interactive-singlekey-doc'Libravatar Junio C Hamano1-1/+5
* vh/config-interactive-singlekey-doc: git-reset.txt: better docs for '--patch' git-checkout.txt: better docs for '--patch' git-stash.txt: better docs for '--patch' git-add.txt: document 'interactive.singlekey' config.txt: 'interactive.singlekey; is used by...
2011-05-05git-add.txt: document 'interactive.singlekey'Libravatar Valentin Haenel1-1/+5
This is documented in the section about the 'Interactive Mode', rather than for the option '--patch', since this is the section is where people go to learn about '--patch'. Helped-by: Jeff King <peff@peff.net> Mentored-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-04git-add.txt: document 'add.ignoreErrors'Libravatar Valentin Haenel1-0/+2
Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de> Noticed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-8/+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-01-04Fix typos in the documentationLibravatar Ralf Wildenhues1-1/+1
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09docs: give more hints about how "add -e" worksLibravatar Jeff King1-28/+76
The previous text was not exactly accurate; it is OK to change space and minus lines, but only in certain ways. This patch takes a whole new approach, which is to describe the sorts of conceptual operations you might want to perform. It also includes a healthy dose of warnings about how things can go wrong. Since the size of the text is getting quite long, it also splits this out into an "editing patches" section. This makes more sense with the current structure, anyway, which already splits out the interactive mode description. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-21docs: give more hints about how "add -e" worksLibravatar Jeff King1-3/+29
The previous text was not exactly accurate; it is OK to change space and minus lines, but only in certain ways. This patch attempts to cover explicitly what can be done at the individual line level, and cautions the user that conceptually larger changes (like modifying a line) require some understanding of the patch format. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'jc/maint-doc-em-dash'Libravatar Junio C Hamano1-1/+1
* jc/maint-doc-em-dash: Work around em-dash handling in newer AsciiDoc
2010-08-24Work around em-dash handling in newer AsciiDocLibravatar Junio C Hamano1-1/+1
Older versions of AsciiDoc used to literally pass double dashes when we used them in our linkgit macros and manpage titles, but newer ones (the issue was first reported with AsciiDoc 8.5.2) turn them into em dashes. Define litdd (literal double-dash) custom attribute in asciidoc.conf to work this around. While we are at it, fix a few double-dashes (e.g. the description of "project--devo--version" convention used by tla, among other things) that used to be incorrectly written as em dashes in the body text to also use this attribute. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: clarify quoting in "git add" exampleLibravatar Jonathan Nieder1-2/+2
The intended text looks like this: · Adds content from all *.txt files under Documentation directory and its subdirectories: $ git add Documentation/\*.txt Note that the asterisk * is quoted from the shell in this example; this lets the command include the files from subdirectories of Documentation/ directory. The current asciidoc 8.5.2 output has a backslash before _every_ asterisk, which is more confusing than it needs to be. Reported-by: Frédéric Brière <fbriere@fbriere.net> Cc: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-19git add: Add --ignore-missing to SYNOPSISLibravatar Ævar Arnfjörð Bjarmason1-1/+2
All the git add options were listed in the synopsis until the --ignore-missing option was added. Change that so that the git add documentation now has the complete listing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-12git add: Add the "--ignore-missing" option for the dry runLibravatar Jens Lehmann1-1/+8
Sometimes it is useful to know if a file or directory will be ignored before it is added to the work tree. An example is "git submodule add", where it would be really nice to be able to fail with an appropriate error message before the submodule is cloned and checked out. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13add-interactive: Clarify “remaining hunks in the file”Libravatar Jonathan Nieder1-3/+3
The "a" and "d" commands to ‘add --patch’ (accept/reject rest of file) interact with "j", "g", and "/" (skip some hunks) in a perhaps confusing way: after accepting or rejecting all _later_ hunks in the file, they return to the earlier, skipped hunks and prompt the user about them again. This behavior can be very useful in practice. One can still accept or reject _all_ undecided hunks in a file by using the "g" command to move to hunk #1 first. 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-02-08Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: blame: prevent a segv when -L given start > EOF git-push: document all the status flags used in the output Fix parsing of imap.preformattedHTML and imap.sslverify git-add documentation: Fix shell quoting example
2010-02-08Merge branch 'jc/maint-doc-git-add-example' into maintLibravatar Junio C Hamano1-1/+1
* jc/maint-doc-git-add-example: git-add documentation: Fix shell quoting example
2010-02-08git-add documentation: Fix shell quoting exampleLibravatar Junio C Hamano1-1/+1
When 921177f (Documentation: improve "add", "pull" and "format-patch" examples, 2008-05-07) converted this from enumeration header to displayed text, it failed to adjust for the AsciiDoc's rule to quote backslashes. In displayed text, backslash is shown verbatim, while in enumeration header, we need to double it. We have a similar construct in git-rm.txt documentation, and need to be careful when somebody wants to update it to match the style of the "git add" example. Noticed by: Greg Bacon <gbacon@dbresearch.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: format full commands in typewriter fontLibravatar Thomas Rast1-1/+1
Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2009-12-07git-add/rm doc: Consistently back-quoteLibravatar Björn Gustavsson1-12/+12
Consistently back-quote commands, options and file names. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07Documentation: 'git add -A' can remove filesLibravatar Björn Gustavsson1-13/+20
The current documentation fails to mention that 'git add -A/--all' can remove files as well as add them, and it also does not say anything about filepatterns (whether they are allowed, mandatory, or optional). It is also not clear what the similarities and differences to the -u option are. Update the intro paragraph (as suggested by Junio, with some minor edits) to make it clear that 'git add' is able to delete and to also cover the -p option. Reword the description of -u to make it clearer (based on Björn Steinbrink's suggestion). Simplify the description of -A by saying "Like -u" and then describe the differences (based on the suggestions by Björn Steinbrink and Junio). Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-14git-add.txt: fix formatting of --patch sectionLibravatar Stephen Boyd1-4/+4
Extra paragraphs should be prefixed with a plus sign. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Improve --patch option documentation in git-addLibravatar Jari Aalto1-3/+8
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Documentation: add: <filepattern>... is optionalLibravatar Paul Bolle1-1/+1
<filepattern>... is optional (e.g. when the --all or --update options are used) so use square brackets in the synopsis. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-18Merge branch 'js/add-edit'Libravatar Junio C Hamano1-1/+10
* js/add-edit: t3702: fix reliance on SHELL_PATH being '/bin/sh' git-add: introduce --edit (to edit the diff vs. the index)
2009-04-16Update git-add.txt according to the new possibilities of 'git add -p'.Libravatar Matthieu Moy1-1/+3
The text is merely cut-and-pasted from git-add--interactive.perl. The cut-and-paste also fixes a typo. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-15git add -p: new "quit" command at the prompt.Libravatar Matthieu Moy1-0/+1
There's already 'd' to stop staging hunks in a file, but no explicit command to stop the interactive staging (for the current files and the remaining ones). Of course you can do 'd' and then ^C, but it would be more intuitive to allow 'quit' action. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12git-add: introduce --edit (to edit the diff vs. the index)Libravatar Johannes Schindelin1-1/+10
With "git add -e [<files>]", Git will fire up an editor with the current diff relative to the index (i.e. what you would get with "git diff [<files>]"). Now you can edit the patch as much as you like, including adding/removing lines, editing the text, whatever. Make sure, though, that the first character of the hunk lines is still a space, a plus or a minus. After you closed the editor, Git will adjust the line counts of the hunks if necessary, thanks to the --recount option of apply, and commit the patch. Except if you deleted everything, in which case nothing happens (for obvious reasons). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-05Merge branch 'jc/add-p-unquote'Libravatar Junio C Hamano1-7/+0
* jc/add-p-unquote: git-add -i/-p: learn to unwrap C-quoted paths
2009-02-28Documentation: minor grammatical fixes.Libravatar David J. Mellor1-6/+6
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18git-add -i/-p: learn to unwrap C-quoted pathsLibravatar Junio C Hamano1-7/+0
The underlying plumbing commands are not run with -z option, so the paths returned from them need to be unquoted as needed. Remove the now stale BUGS section from git-add documentaiton as suggested by Teemu Likonen. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-27Fix typos in the documentation.Libravatar Ralf Wildenhues1-1/+1
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-20document "intent to add" option to git-addLibravatar Jeff King1-2/+11
This was added by 3942581 but never documented. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-19git-add --all: documentationLibravatar Junio C Hamano1-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-15Make git-add -i accept ranges like 7-Libravatar Ciaran McCreesh1-2/+3
git-add -i ranges expect number-number. But for the supremely lazy, typing in that second number when selecting "from patch 7 to the end" is wasted effort. So treat an empty second number in a range as "until the last item". Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-02git-add--interactive: manual hunk editing modeLibravatar Thomas Rast1-0/+1
Adds a new option 'e' to the 'add -p' command loop that lets you edit the current hunk in your favourite editor. If the resulting patch applies cleanly, the edited hunk will immediately be marked for staging. If it does not apply cleanly, you will be given an opportunity to edit again. If all lines of the hunk are removed, then the edit is aborted and the hunk is left unchanged. Applying the changed hunk(s) relies on Johannes Schindelin's new --recount option for git-apply. Note that the "real patch" test intentionally uses (echo e; echo n; echo d) | git add -p even though the 'n' and 'd' are superfluous at first sight. They serve to get out of the interaction loop if git add -p wrongly concludes the patch does not apply. Many thanks to Jeff King <peff@peff.net> for lots of help and suggestions. Signed-off-by: Thomas Rast <trast@student.ethz.ch> 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-07-01Documentation: fix links to tutorials and other new manual pagesLibravatar Jonathan Nieder1-1/+1
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-14git add: add long equivalents of '-u' and '-f' optionsLibravatar SZEDER Gábor1-2/+5
The option -u stands for --update and it is a good idea to make it clear especially because this is the only mode of operation of "git add" that does something different from "adding". Give longer --force synonym to -f while we are at it as well. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-6/+10
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>
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-05-28Manual subsection to refer to other pages is SEE ALSOLibravatar Junio C Hamano1-1/+1
Consistently say so in all caps as it is customary to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Add --ignore-errors to git-add to allow it to skip files with read errorsLibravatar Alex Riesen1-1/+6
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08Merge branch 'maint'Libravatar Junio C Hamano1-1/+3
* maint: Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull" doc: clarify definition of "update" for git-add -u
2008-05-08Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-1/+3
* maint-1.5.4: Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull" doc: clarify definition of "update" for git-add -u
2008-05-08doc: clarify definition of "update" for git-add -uLibravatar Jeff King1-1/+3
The "-u" option is described only in terms of "updating" files, which in turn is described only as "similar to what git commit -a does". Let's be a little more specific about what updating entails. Suggested by Geoffrey Irving. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-06Documentation: improve "add", "pull" and "format-patch" examplesLibravatar Christian Couder1-9/+15
Before this patch in "git-add.txt" and "git-format-patch.txt", the commands used in the examples were "git-CMD" instead of "git CMD". This patch fixes that. In "git-pull.txt" only the last example had the code sample in an asciidoc "Listing Block", and in the other two files, none. This patch fixes that by putting all code samples in listing blocks. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-02Describe the bug in handling filenames with funny characters in 'git add -i'Libravatar Teemu Likonen1-0/+6
The interactive mode does not work with files whose names contain characters that need C-quoting. `core.quotepath` configuration can be used to work this limitation around to some degree, but backslash, double-quote and control characters will still have problems. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13Minor wording changes in the keyboard descriptions in git-add --interactive.Libravatar Vineet Kumar1-10/+8
The wording of the interactive help text from git-add--interactive.perl is clearer. Just duplicate that text here. Signed-off-by: Vineet Kumar <vineet@doorstop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20Clarified the meaning of git-add -u in the documentationLibravatar Pekka Kaitaniemi1-2/+2
The git-add documentation did not state clearly that the -u switch updates only the tracked files that are in the current directory and its subdirectories. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-8/+8
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>