summaryrefslogtreecommitdiff
path: root/Documentation/git-status.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-10-03Merge branch 'mr/doc-negative-pathspec'Libravatar Junio C Hamano1-0/+2
Doc updates. * mr/doc-negative-pathspec: docs: improve discoverability of exclude pathspec
2017-09-25docs: improve discoverability of exclude pathspecLibravatar Manav Rathi1-0/+2
The ability to exclude paths with a negative pathspec is not mentioned in the man pages for git grep and other commands where it might be useful. Add an example and a pointer to the pathspec glossary entry in the man page for git grep to help the user to discover this ability. Add similar pointers from the git-add and git-status man pages. Additionally, - Add a test for the behaviour when multiple exclusions are present. - Add a test for the ^ alias. - Improve name of existing test. - Improve grammar in glossary description of the exclude pathspec. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Manav Rathi <mnvrth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18status: add optional stash count informationLibravatar Liam Beguin1-0/+3
Introduce '--show-stash' and its configuration option 'status.showStash' to allow git-status to show information about currently stashed entries. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-29submodule.c: correctly handle nested submodules in is_submodule_modifiedLibravatar Stefan Beller1-0/+2
Suppose I have a superproject 'super', with two submodules 'super/sub' and 'super/sub1'. 'super/sub' itself contains a submodule 'super/sub/subsub'. Now suppose I run, from within 'super': echo hi >sub/subsub/stray-file echo hi >sub1/stray-file Currently we get would see the following output in git-status: git status --short m sub ? sub1 With this patch applied, the untracked file in the nested submodule is displayed as an untracked file on the 'super' level as well. git status --short ? sub ? sub1 This doesn't change the output of 'git status --porcelain=1' for nested submodules, because its output is always ' M' for either untracked files or local modifications no matter the nesting level of the submodule. 'git status --porcelain=2' is affected by this change in a nested submodule, though. Without this patch it would report the direct submodule as modified and having no untracked files. With this patch it would report untracked files. Chalk this up as a bug fix. This bug fix also affects the default output (non-short, non-porcelain) of git-status, which is not tested here. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-29short status: improve reporting for submodule changesLibravatar Stefan Beller1-0/+11
If I add an untracked file to a submodule or modify a tracked file, currently "git status --short" treats the change in the same way as changes to the current HEAD of the submodule: $ git clone --quiet --recurse-submodules https://gerrit.googlesource.com/gerrit $ echo hello >gerrit/plugins/replication/stray-file $ sed -i -e 's/.*//' gerrit/plugins/replication/.mailmap $ git -C gerrit status --short M plugins/replication This is by analogy with ordinary files, where "M" represents a change that has not been added yet to the index. But this change cannot be added to the index without entering the submodule, "git add"-ing it, and running "git commit", so the analogy is counterproductive. Introduce new status letters " ?" and " m" for this. These are similar to the existing "??" and " M" but mean that the submodule (not the parent project) has new untracked files and modified files, respectively. The user can use "git add" and "git commit" from within the submodule to add them. Changes to the submodule's HEAD commit can be recorded in the index with a plain "git add -u" and are shown with " M", like today. To avoid excessive clutter, show at most one of " ?", " m", and " M" for the submodule. They represent increasing levels of change --- the last one that applies is shown (e.g., " m" if there are both modified files and untracked files in the submodule, or " M" if the submodule's HEAD has been modified and it has untracked files). While making these changes, we need to make sure to not break porcelain level 1, which shares code with "status --short". We only change "git status --short". Non-short "git status" and "git status --porcelain=2" already handle these cases by showing more detail: $ git -C gerrit status --porcelain=2 1 .M S.MU 160000 160000 160000 305c864db28eb0c77c8499bc04c87de3f849cf3c 305c864db28eb0c77c8499bc04c87de3f849cf3c plugins/replication $ git -C gerrit status [...] modified: plugins/replication (modified content, untracked content) Scripts caring about these distinctions should use --porcelain=2. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02Documentation: improve description for core.quotePathLibravatar Andreas Heiduk1-4/+3
Linking the description for pathname quoting to the configuration variable "core.quotePath" removes inconstistent and incomplete sections while also giving two hints how to deal with it: Either with "-c core.quotePath=false" or with "-z". Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11git-status.txt: describe --porcelain=v2 formatLibravatar Jeff Hostetler1-4/+122
Update status manpage to include information about porcelain v2 format. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05status: support --porcelain[=<version>]Libravatar Jeff Hostetler1-2/+5
Update --porcelain argument to take optional version parameter to allow multiple porcelain formats to be supported in the future. The token "v1" is the default value and indicates the traditional porcelain format. (The token "1" is an alias for that.) Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-21Documentation: explain optional arguments betterLibravatar Matthieu Moy1-2/+3
Improve the documentation of commands taking optional arguments in two ways: * Documents the behavior of '-O' (for grep) and '-S' (for commands creating commits) when used without the optional argument. * Document the syntax of these options. For the second point, the behavior is documented in gitcli(7), but it is easy for users to miss, and hard for the same user to understand why e.g. "git status -u no" does not work. Document this explicitly in the documentation of each short option having an optional argument: they are the most error prone since there is no '=' sign between the option and its argument. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-26Merge branch 'nd/untracked-cache'Libravatar Junio C Hamano1-1/+4
Teach the index to optionally remember already seen untracked files to speed up "git status" in a working tree with tons of cruft. * nd/untracked-cache: (24 commits) git-status.txt: advertisement for untracked cache untracked cache: guard and disable on system changes mingw32: add uname() t7063: tests for untracked cache update-index: test the system before enabling untracked cache update-index: manually enable or disable untracked cache status: enable untracked cache untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE untracked cache: mark index dirty if untracked cache is updated untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS untracked cache: avoid racy timestamps read-cache.c: split racy stat test to a separate function untracked cache: invalidate at index addition or removal untracked cache: load from UNTR index extension untracked cache: save to an index extension ewah: add convenient wrapper ewah_serialize_strbuf() untracked cache: don't open non-existent .gitignore untracked cache: mark what dirs should be recursed/saved untracked cache: record/validate dir mtime and reuse cached output untracked cache: make a wrapper around {open,read,close}dir() ...
2015-04-28Merge branch 'mg/status-v-v'Libravatar Junio C Hamano1-0/+8
* mg/status-v-v: status: document the -v/--verbose option
2015-04-23status: document the -v/--verbose optionLibravatar Michael Haggerty1-0/+8
Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-12git-status.txt: advertisement for untracked cacheLibravatar Nguyễn Thái Ngọc Duy1-1/+4
When a good user sees the "too long, consider -uno" advice when running `git status`, they should check out the man page to find out more. This change suggests they try untracked cache before -uno. Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19doc: fix 'git status --help' character quotingLibravatar Philip Oakley1-2/+2
Correct backtick quoting for some of the modification states to give consistent web rendering. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'dw/doc-status-no-longer-shows-pound-prefix'Libravatar Junio C Hamano1-1/+1
* dw/doc-status-no-longer-shows-pound-prefix: doc: status, remove leftover statement about '#' prefix
2014-03-21doc: status, remove leftover statement about '#' prefixLibravatar Dirk Wallenstein1-1/+1
This hasn't been true since 2556b996 (status: disable display of '#' comment prefix by default, 2013-09-06). Signed-off-by: Dirk Wallenstein <halsmit@t-online.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11Improve documentation concerning the status.submodulesummary settingLibravatar Jens Lehmann1-1/+7
'git status' and 'git commit' can be told to also show the output of "git submodule summary" by setting the "status.submodulesummary" config option. But status and commit also honor the "diff.ignoreSubmodules" and the "submodule.<name>.ignore" settings, which then disable the summary partly or completely. This - and the fact that the last two settings do not affect the "git submodule" commands at all - is not well documented. Extend the documentation in those places where "status.submodulesummary", "diff.ignoreSubmodules" and "submodule.<name>.ignore" are described to better explain these dependencies. Thanks-to: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21Merge branch 'tb/document-status-u-tradeoff'Libravatar Junio C Hamano1-4/+10
Suggest users to look into using--untracked=no option when "git status" takes too long. * tb/document-status-u-tradeoff: status: advise to consider use of -u when read_directory takes too long git status: document trade-offs in choosing parameters to the -u option
2013-03-15git status: document trade-offs in choosing parameters to the -u optionLibravatar Junio C Hamano1-4/+10
In some repostories users experience that "git status" command takes long time. The command spends some time searching the file system for untracked files. Explain the trade-off struck by the default choice of `normal` to help users make an appropriate choice better, before talking about the configuration variable. Inspired by Torsten Bögershausen. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18status: add --long output format optionLibravatar Jeff King1-0/+3
You can currently set the output format to --short or --porcelain. There is no --long, because we default to it already. However, you may want to override an alias that uses "--short" to get back to the default. This requires a little bit of refactoring, because currently we use STATUS_FORMAT_LONG internally to mean the same as "the user did not specify anything". By expanding the enum to include STATUS_FORMAT_NONE, we can distinguish between the implicit and explicit cases. This effects these conditions: 1. The user has asked for NUL termination. With NONE, we currently default to turning on the porcelain mode. With an explicit --long, we would in theory use NUL termination with the long mode, but it does not support it. So we can just complain and die. 2. When an output format is given to "git commit", we default to "--dry-run". This behavior would now kick in when "--long" is given, too. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-08Merge branch 'jk/maint-status-porcelain-z-b' into HEADLibravatar Jeff King1-1/+1
* jk/maint-status-porcelain-z-b: status: respect "-b" for porcelain format status: fix null termination with "-b" status: refactor null_termination option commit: refactor option parsing Conflicts: wt-status.h
2012-05-08status: respect "-b" for porcelain formatLibravatar Jeff King1-1/+1
There is no reason not to, as the user has to explicitly ask for it, so we are not breaking compatibility by doing so. We can do this simply by moving the "show_branch" flag into the wt_status struct. As a bonus, this saves us from passing it explicitly, simplifying the code. Signed-off-by: Jeff King <peff@peff.net>
2012-05-03Merge branch 'nd/columns'Libravatar Junio C Hamano1-0/+7
A couple of commands learn --column option to produce columnar output. By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1) * nd/columns: tag: add --column column: support piping stdout to external git-column process status: add --column branch: add --column help: reuse print_columns() for help -a column: add dense layout support t9002: work around shells that are unable to set COLUMNS to 1 column: add columnar layout Stop starting pager recursively Add column layout skeleton and git-column
2012-04-27status: add --columnLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-2/+2
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-07-22Merge branch 'mz/doc-synopsis-verse'Libravatar Junio C Hamano1-0/+1
* mz/doc-synopsis-verse: Documentation: use [verse] for SYNOPSIS sections Conflicts: Documentation/git-mergetool--lib.txt
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-06-29Merge branch 'jk/maint-1.7.2-status-ignored'Libravatar Junio C Hamano1-1/+6
* jk/maint-1.7.2-status-ignored: git status --ignored: tests and docs status: fix bug with missing --ignore files Conflicts: Documentation/git-status.txt t/t7508-status.sh
2011-06-02git status --ignored: tests and docsLibravatar Junio C Hamano1-0/+6
Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26docs: make sure literal "->" isn't converted to arrowLibravatar Jeff King1-4/+4
Recent versions of asciidoc will treat "->" as a single-glyph arrow symbol, unless it is inside a literal code block. This is a problem if we are discussing literal output and want to show the ASCII characters. Our usage falls into three categories: 1. Inside a code block. These can be left as-is. 2. Discussing literal output or code, but inside a paragraph. This patch escapes these as "\->". 3. Using the arrow as a symbolic element, such as "use the Edit->Account Settings menu". In this case, the arrow symbol is preferable, so we leave it as-is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26docs: update status --porcelain formatLibravatar Jeff King1-4/+23
The --porcelain format was originally identical to the --short format, but designed to be stable as the short format changed. Since this was written, the short format picked up a few incompatible niceties, but this description was never changed. Let's mention the differences. While we're at it, let's add some sub-section headings to make the "output" section a little easier to navigate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26docs: minor grammar fixes to git-statusLibravatar Jeff King1-3/+4
Signed-off-by: Jeff King <peff@peff.net> 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-02-21Documentation: clarify -u<mode> option defaultsLibravatar Clemens Buchacher1-8/+8
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-09Submodules: Use "ignore" settings from .gitmodules too for diff and statusLibravatar Jens Lehmann1-1/+1
The .gitmodules file is parsed for "submodule.<name>.ignore" entries before looking for them in .git/config. Thus settings found in .git/config will override those from .gitmodules, thereby allowing the local developer to ignore settings given by the remote side while also letting upstream set defaults for those users who don't have special needs. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-09Submodules: Add the new "ignore" config option for diff and statusLibravatar Jens Lehmann1-1/+5
The new "ignore" config option controls the default behavior for "git status" and the diff family. It specifies under what circumstances they consider submodules as modified and can be set separately for each submodule. The command line option "--ignore-submodules=" has been extended to accept the new parameter "none" for both status and diff. Users that chose submodules to get rid of long work tree scanning times might want to set the "dirty" option for those submodules. This brings back the pre 1.7.0 behavior, where submodule work trees were never scanned for modifications. By using "--ignore-submodules=none" on the command line the status and diff commands can be told to do a full scan. This option can be set to the following values (which have the same name and meaning as for the "--ignore-submodules" option of status and diff): "all": All changes to the submodule will be ignored. "dirty": Only differences of the commit recorded in the superproject and the submodules HEAD will be considered modifications, all changes to the work tree of the submodule will be ignored. When using this value, the submodule will not be scanned for work tree changes at all, leading to a performance benefit on large submodules. "untracked": Only untracked files in the submodules work tree are ignored, a changed HEAD and/or modified files in the submodule will mark it as modified. "none" (which is the default): Either untracked or modified files in a submodules work tree or a difference between the subdmodules HEAD and the commit recorded in the superproject will make it show up as changed. This value is added as a new parameter for the "--ignore-submodules" option of the diff family and "git status" so the user can override the settings in the configuration. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jl/status-ignore-submodules'Libravatar Junio C Hamano1-0/+11
* jl/status-ignore-submodules: Add the option "--ignore-submodules" to "git status" git submodule: ignore dirty submodules for summary and status Conflicts: builtin/commit.c t/t7508-status.sh wt-status.c wt-status.h
2010-06-25Add the option "--ignore-submodules" to "git status"Libravatar Jens Lehmann1-0/+11
In some use cases it is not desirable that "git status" considers submodules that only contain untracked content as dirty. This may happen e.g. when the submodule is not under the developers control and not all build generated files have been added to .gitignore by the upstream developers. Using the "untracked" parameter for the "--ignore-submodules" option disables checking for untracked content and lets git diff report them as changed only when they have new commits or modified content. Sometimes it is not wanted to have submodules show up as changed when they just contain changes to their work tree (this was the behavior before 1.7.0). An example for that are scripts which just want to check for submodule commits while ignoring any changes to the work tree. Also users having large submodules known not to change might want to use this option, as the - sometimes substantial - time it takes to scan the submodule work tree(s) is saved when using the "dirty" parameter. And if you want to ignore any changes to submodules, you can now do that by using this option without parameters or with "all" (when the config option status.submodulesummary is set, using "all" will also suppress the output of the submodule summary). A new function handle_ignore_submodules_arg() is introduced to parse this option new to "git status" in a single location, as "git diff" already knew it. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-03Documentation+t5708: document and test status -s -bLibravatar Michael J Gruber1-1/+9
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-23Documentation improvements for the description of short format.Libravatar Eric Raymond1-9/+34
Incorporates the detailed explanation from Jeff King in <20100410040959.GA11977@coredump.intra.peff.net> and fixes the bug noted by Junio C Hamano in <7vmxxc1i8g.fsf@alter.siamese.dyndns.org>. Signed-off-by: Eric S. Raymond <esr@thyrsus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-1/+1
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-11-26status -s: respect the status.relativePaths optionLibravatar Michael J Gruber1-2/+2
Otherwise, 'status' and 'status -s' in a subdir would produce different names. This change is all the more important because status.relativePaths is on by default. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-05docs: note that status configuration affects only long formatLibravatar Jeff King1-5/+5
The short format does not respect any of the usual status.* configuration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-05status: add --porcelain output formatLibravatar Jeff King1-2/+7
The "short" format was added to "git status" recently to provide a less verbose way of looking at the same information. This has two practical uses: 1. Users who want a more dense display of the information. 2. Scripts which want to parse the information and need a stable, easy-to-parse interface. For now, the "--short" format covers both of those uses. However, as time goes on, users of (1) may want additional format tweaks, or for "git status" to change its behavior based on configuration variables. Those wishes will be at odds with (2), which wants to stability for scripts. This patch introduces a separate --porcelain option early to avoid problems later on. Right now the --short and --porcelain outputs are identical. However, as time goes on, we will have the freedom to customize --short for human consumption while keeping --porcelain stable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-22git status: not "commit --dry-run" anymoreLibravatar Junio C Hamano1-10/+69
This removes tentative "git stat" and make it take over "git status". There are some tests that expect "git status" to exit with non-zero status when there is something staged. Some tests expect "git status path..." to show the status for a partial commit. For these, replace "git status" with "git commit --dry-run". For the ones that do not attempt a dry-run of a partial commit that check the output from the command, check the output from "git status" as well, as they should be identical. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Update my e-mail addressLibravatar Junio C Hamano1-1/+1
The old cox.net address is still getting mails from gitters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-3/+3
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: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-3/+3
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>