summaryrefslogtreecommitdiff
path: root/Documentation/git-rm.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-09-28rm: add --sparse optionLibravatar Derrick Stolee1-0/+6
As we did previously in 'git add', add a '--sparse' option to 'git rm' that allows modifying paths outside of the sparse-checkout definition. The existing checks in 'git rm' are restricted to tracked files that have the SKIP_WORKTREE bit in the current index. Future changes will cause 'git rm' to reject removing paths outside of the sparse-checkout definition, even if they are untracked or do not have the SKIP_WORKTREE bit. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-08rm: honor sparse checkout patternsLibravatar Matheus Tavares1-1/+3
`git add` refrains from adding or updating index entries that are outside the current sparse checkout, but `git rm` doesn't follow the same restriction. This is somewhat counter-intuitive and inconsistent. So make `rm` honor the sparsity rules and advise on how to remove SKIP_WORKTREE entries just like `add` does. Also add some tests for the new behavior. Suggested-by: Elijah Newren <newren@gmail.com> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19rm: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy1-1/+16
Decisions taken for simplicity: 1) It is not allowed to pass pathspec in both args and file. Adjustments were needed for `if (!argc)` block: This code actually means "pathspec is not present". Previously, pathspec could only come from commandline arguments, so testing for `argc` was a valid way of testing for the presence of pathspec. But this is no longer true with `--pathspec-from-file`. During the entire `--pathspec-from-file` story, I tried to keep its behavior very close to giving pathspec on commandline, so that switching from one to another doesn't involve any surprises. However, throwing usage at user in the case of empty `--pathspec-from-file` would puzzle because there's nothing wrong with "usage" (that is, argc/argv array). On the other hand, throwing usage in the old case also feels bad to me. While it's less of a puzzle, I (as user) never liked the experience of comparing my commandline to "usage", trying to spot a difference. Since it's already known what the error is, it feels a lot better to give that specific error to user. Judging from [1] it doesn't seem that showing usage in this case was important (the patch was to avoid segfault), and it doesn't fit into how other commands react to empty pathspec (see for example `git add` with a custom message). Therefore, I decided to show new error text in both cases. In order to continue testing for error early, I moved `parse_pathspec()` higher. Now it happens before `read_cache()` / `hold_locked_index()` / `setup_work_tree()`, which shouldn't cause any issues. [1] Commit 7612a1ef ("git-rm: honor -n flag" 2006-06-09) Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-21doc: rm: synchronize <pathspec> descriptionLibravatar Alexandr Miloslavskiy1-29/+21
This patch continues the effort that is already applied to `git commit`, `git reset`, `git checkout` etc. 1) Changed outdated descriptions to mention pathspec instead. 2) Added reference to 'linkgit:gitglossary[7]'. 3) Removed content that merely repeated gitglossary. 4) Merged the remainder of "discussion" into `<patchspec>`. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.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-07-12Merge branch 'sb/submodule-doc'Libravatar Junio C Hamano1-2/+2
Doc update. * sb/submodule-doc: submodules: overhaul documentation
2017-06-22submodules: overhaul documentationLibravatar Stefan Beller1-2/+2
This patch aims to detangle (a) the usage of `git-submodule` from (b) the concept of submodules and (c) how the actual implementation looks like, such as where they are configured and (d) what the best practices are. To do so, move the conceptual parts of the 'git-submodule' man page to a new man page gitsubmodules(7). This new page is just like gitmodules(5), gitattributes(5), gitcredentials(7), gitnamespaces(7), gittutorial(7), which introduce a concept rather than explaining a specific command. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-04Documentation/git-rm: correct submodule descriptionLibravatar Stefan Beller1-4/+5
Since 3ccd681c2a (Merge branch 'sb/submodule-rm-absorb', 2017-01-18) git-rm tries to absorb any submodules git dir before deleting the submodule. Correct the documentation to say so. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07rm: better document side effects when removing a submoduleLibravatar Jens Lehmann1-0/+9
The "Submodules" section of the "git rm" documentation mentions what will happen when a submodule with a gitfile gets removed with newer git. But it doesn't talk about what happens when the user changes between commits before and after the removal, which does not remove the submodule from the work tree like using the rm command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06rm: delete .gitmodules entry of submodules removed from the work treeLibravatar Jens Lehmann1-3/+5
Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-0/+4
There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "submodule init". "submodule deinit" is the way to do so. * jl/submodule-deinit: submodule: add 'deinit' command
2013-03-04submodule: add 'deinit' commandLibravatar Jens Lehmann1-0/+4
With "git submodule init" the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to "git submodule update". But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the "submodule.$name.url" setting from .git/config together with the work tree himself). Help those users by providing a 'deinit' command. This removes the whole submodule.<name> section from .git/config (either for the given submodule(s) or for all those which have been initialized if '.' is used) together with their work tree. Fail if the current work tree contains modifications (unless forced), but don't complain when either the work tree is already removed or no settings are found in .git/config. Add tests and link the man pages of "git submodule deinit" and "git rm" to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Also add the deinit subcommand to the completion list. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.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-5/+5
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-14docs: move submodule sectionLibravatar Matt Kraai1-15/+15
293ab15e ("submodule: teach rm to remove submodules unless they contain a git directory", 2012-09-26) inserted the "Submodules" section between a sentence describing a command and the command. Move the "Submodules" section further down. Noticed-by: Horst H. von Brand Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29submodule: teach rm to remove submodules unless they contain a git directoryLibravatar Jens Lehmann1-0/+15
Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-2/+1
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04docs: put listed example commands in backticksLibravatar Jeff King1-2/+2
Many examples of git command invocation are given in asciidoc listing blocks, which makes them monospaced and avoids further interpretation of special characters. Some manpages make a list of examples, like: git foo:: Run git foo. git foo -q:: Use the "-q" option. to quickly show many variants. However, they can sometimes be hard to read, because they are shown in a proportional-width font (so, for example, seeing the difference between "-- foo" and "--foo" can be difficult). This patch puts all such examples into backticks, which gives the equivalent formatting to a listing block (i.e., monospaced and without character interpretation). As a bonus, this also fixes an example in the git-push manpage, in which "git push origin :::" was accidentally considered a newly-indented list, and not a list item with "git push origin :" in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-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.
2010-12-07git-rm.txt: Fix quotingLibravatar Michael J Gruber1-6/+6
Literal " produces typographically incorrect quotations, but "works" in most circumstances. In the subheadings of git-rm.txt, it "works" for the html backend but not for the docbook conversion to nroff: double "" and spurious double spaces appear in the output. Replace "incorrect" quotations by ``correct'' ones, and fix other "quotations" which are really `code fragments`. This should make git-rm.txt "-clean. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: clarify quoting in "git rm" exampleLibravatar Jonathan Nieder1-3/+3
Intended output: git rm Documentation/\*.txt Removes all *.txt files from the index that are under the Documentation directory and any of its subdirectories. Note that the asterisk * is quoted from the shell in this example; this lets git, and not the shell, expand the pathnames of files and subdirectories under the Documentation/ directory. Without this change, there are too many backslashes output. Tested with asciidoc 8.5.2. Reported-by: Frédéric Brière <fbriere@fbriere.net> Cc: Carl Worth <cworth@cworth.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: quoting trouble in "git rm" discussionLibravatar Jonathan Nieder1-1/+2
The current output (with Asciidoc 8.5.2) seems a bit broken: given two directories ‘d` and d2, there is a difference between using git rm 'd*’ and ‘git rm 'd/\*\’`, as the former will also remove all of directory d2. In other words, the markup parses as given two directories << d` and _d2_, there is a difference between using _git rm 'd* >>_ and << git rm 'd/\*\ >> `. I suspect there is an asciidoc bug involved (why is ' a candidate closing-quote mark when it is preceded by a backslash?) but with all the meanings of ` and ' involved I do not want to track it down. Better to use unambiguous {asterisk} and {apostrophe} entities. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-07git-rm doc: Describe how to sync index & work treeLibravatar Björn Gustavsson1-1/+53
Newcomers to git that want to remove from the index only the files that have disappeared from the working tree will probably look for a way to do that in the documentation for 'git rm'. Therefore, describe how that can be done (even though it involves other commands than 'git rm'). Based on a suggestion by Junio, but re-arranged and rewritten to better fit into the style of command reference. While at it, change a single occurrence of "work tree" to "working tree" for consistency. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07git-add/rm doc: Consistently back-quoteLibravatar Björn Gustavsson1-3/+3
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>
2008-08-08builtin-rm: Add a --force flagLibravatar Pieter de Bie1-1/+2
This adds a --force flag to git-rm, making it somewhat easier for subversion people to switch. Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-2/+2
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-1/+1
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-4/+4
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-4/+6
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-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-04-16Clarify and fix English in "git-rm" documentationLibravatar Jon Loeliger1-20/+32
Do some verb-noun agreement changes. Clarify some file globbing cases. Fixed a wrong statement in an example. Signed-off-by: Jon Loeliger <jdl@jdl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-2/+2
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>
2007-10-29Update manpages to reflect new short and long option aliasesLibravatar Jonas Fonseca1-2/+2
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-13More permissive "git-rm --cached" behavior without -f.Libravatar Matthieu Moy1-1/+2
In the previous behavior, "git-rm --cached" (without -f) had the same restriction as "git-rm". This forced the user to use the -f flag in situations which weren't actually dangerous, like: $ git add foo # oops, I didn't want this $ git rm --cached foo # back to initial situation Previously, the index had to match the file *and* the HEAD. With --cached, the index must now match the file *or* the HEAD. The behavior without --cached is unchanged, but provides better error messages. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-17Add --ignore-unmatch option to exit with zero status when no files are removed.Libravatar Steven Grimm1-1/+4
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16Add --quiet option to suppress output of "rm" commands for removed files.Libravatar Steven Grimm1-0/+4
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16git-rm documentation: remove broken behaviour from the example.Libravatar Junio C Hamano1-8/+4
The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-25git-rm: DocumentationLibravatar Junio C Hamano1-24/+27
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05Fix up docs where "--" isn't displayed correctly.Libravatar sean1-1/+1
A bare "--" doesn't show up in man or html pages correctly as two individual dashes unless backslashed as \-- in the asciidoc source. Note, no backslash is needed inside a literal block. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09Remove trailing dot after short descriptionLibravatar Fredrik Kuivinen1-1/+1
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05documentation: add 'see also' sections to git-rm and git-addLibravatar Jeff Muizelaar1-0/+3
Pair up git-add and git-rm by adding a 'see also' section that references the opposite command to each of their documentation files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-22Add new git-rm command with documentationLibravatar Carl Worth1-0/+89
This adds a git-rm command which provides convenience similar to git-add, (and a bit more since it takes care of the rm as well if given -f). Like git-add, git-rm expands the given path names through git-ls-files. This means it only acts on files listed in the index. And it does act recursively on directories by default, (no -r needed as in the case of rm itself). When it recurses, it does not remove empty directories that are left behind. Signed-off-by: Junio C Hamano <junkio@cox.net>