path: root/Documentation/git.txt
AgeCommit message (Collapse)Author
2018-06-01Merge branch 'nd/command-list'Junio C Hamano
The list of commands with their various attributes were spread across a few places in the build procedure, but it now is getting a bit more consolidated to allow more automation. * nd/command-list: completion: allow to customize the completable command list completion: add and use --list-cmds=alias completion: add and use --list-cmds=nohelpers Move declaration for alias.c to alias.h completion: reduce completable command list completion: let git provide the completable command list command-list.txt: documentation and guide line help: use command-list.txt for the source of guides help: add "-a --verbose" to list all commands with synopsis git: support --list-cmds=list-<category> completion: implement and use --list-cmds=main,others git --list-cmds: collect command list in a string_list git.c: convert --list-* to --list-cmds=* Remove common-cmds.h help: use command-list.h for common command list export all commands to command-list.h factor out synopsis extract code
2018-05-21completion: allow to customize the completable command listNguyễn Thái Ngọc Duy
By default we show porcelain, external commands and a couple others that are also popular. If you are not happy with this list, you can now customize it a new config variable. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-21completion: add and use --list-cmds=aliasNguyễn Thái Ngọc Duy
By providing aliases via --list-cmds=, we could simplify command collection code in the script. We only issue one git command. Before this patch that is "git config", after it's "git --list-cmds=". In "git help" completion case we actually reduce one "git" process (for getting guides) but that call was added in this series so it does not really count. A couple of bash functions are removed because they are not needed anymore. __git_compute_all_commands() and $__git_all_commands stay because they are still needed for completing pager.* config and without "alias" group, the result is still cacheable. There is a slight (good) change in _git_help() with this patch: before "git help <tab>" shows external commands (as in _not_ part of git) as well as part of $__git_all_commands. We have finer control over command listing now and can exclude that because we can't provide a man page for external commands anyway. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-21completion: add and use --list-cmds=nohelpersNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-21git: support --list-cmds=list-<category>Nguyễn Thái Ngọc Duy
This allows us to select any group of commands by a category defined in command-list.txt. This is an internal/hidden option so we don't have to be picky about the category name or worried about exposing too much. This will be used later by git-completion.bash to retrieve certain command groups. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-21completion: implement and use --list-cmds=main,othersNguyễn Thái Ngọc Duy
This is part of the effort to break down and provide commands by category in machine-readable form. This could be helpful later on when completion script switches to use --list-cmds for selecting completable commands. It would be much easier for the user to choose to complete _all_ commands instead of the default selection by passing different values to --list-cmds in git-completino.bash. While at there, replace "git help -a" in git-completion.bash with --list-cmds since it's better suited for this task. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-21git.c: convert --list-* to --list-cmds=*Nguyễn Thái Ngọc Duy
Even if these are hidden options, let's make them a bit more generic since we're introducing more listing types shortly. The code is structured to allow combining multiple listing types together because we will soon add more types the 'builtins'. 'parseopt' remains separate because it has separate (SPC) to match git-completion.bash needs and will not combine with others. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-04git: add -P as a short option for --no-pagerJohannes Sixt
It is possible to configure 'less', the pager, to use an alternate screen to show the content, for example, by setting LESS=RS in the environment. When it is closed in this configuration, it switches back to the original screen, and all content is gone. It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. Provide a short option, -P, to make the option more easily accessible. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2018-03-15Merge branch 'ab/man-sec-list'Junio C Hamano
Doc update. * ab/man-sec-list: git manpage: note
2018-03-08git manpage: note git-security@googlegroups.comÆvar Arnfjörð Bjarmason
Add a mention of the security mailing list to the "Reporting Bugs" section. There's a mention of this list at but none in git.git itself. The copy is pasted from the website. Let's use the same wording in both places. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-01-19http: support omitting data from tracesJonathan Tan
GIT_TRACE_CURL provides a way to debug what is being sent and received over HTTP, with automatic redaction of sensitive information. But it also logs data transmissions, which significantly increases the log file size, sometimes unnecessarily. Add an option "GIT_TRACE_CURL_NO_DATA" to allow the user to omit such data transmissions. Signed-off-by: Jonathan Tan <> Signed-off-by: Junio C Hamano <>
2018-01-19http: support cookie redaction when tracingJonathan Tan
When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and "Proxy-Authorization:" HTTP headers. Extend this redaction to a user-specified list of cookies, specified through the "GIT_REDACT_COOKIES" environment variable. Signed-off-by: Jonathan Tan <> Signed-off-by: Junio C Hamano <>
2017-12-19Merge branch 'ar/unconfuse-three-dots'Junio C Hamano
Ancient part of codebase still shows dots after an abbreviated object name just to show that it is not a full object name, but these ellipses are confusing to people who newly discovered Git who are used to seeing abbreviated object names and find them confusing with the range syntax. * ar/unconfuse-three-dots: t2020: test variations that matter t4013: test new output from diff --abbrev --raw diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value t4013: prepare for upcoming "diff --raw --abbrev" output format change checkout: describe_detached_head: remove ellipsis after committish print_sha1_ellipsis: introduce helper Documentation: user-manual: limit usage of ellipsis Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line with "two-dot").
2017-12-06Merge branch 'bw/protocol-v1'Junio C Hamano
A new mechanism to upgrade the wire protocol in place is proposed and demonstrated that it works with the older versions of Git without harming them. * bw/protocol-v1: Documentation: document Extra Parameters ssh: introduce a 'simple' ssh variant i5700: add interop test for protocol transition http: tell server that the client understands v1 connect: tell server that the client understands v1 connect: teach client to recognize v1 server response upload-pack, receive-pack: introduce protocol version 1 daemon: recognize hidden request arguments protocol: introduce protocol extension mechanisms pkt-line: add packet_write function connect: in ref advertisement, shallows are last
2017-12-04print_sha1_ellipsis: introduce helperAnn T Ropea
Introduce a helper print_sha1_ellipsis() that pays attention to the GIT_PRINT_SHA1_ELLIPSIS environment variable, and prepare the tests to unconditionally set it for the test pieces that will be broken once the code stops showing the extra dots by default. The removal of these dots is merely a plan at this step and has not happened yet but soon will. Document GIT_PRINT_SHA1_ELLIPSIS. Signed-off-by: Ann T Ropea <> Signed-off-by: Junio C Hamano <>
2017-11-21Merge branch 'av/fsmonitor'Junio C Hamano
Various fixes to bp/fsmonitor topic. * av/fsmonitor: fsmonitor: simplify determining the git worktree under Windows fsmonitor: store fsmonitor bitmap before splitting index fsmonitor: read from getcwd(), not the PWD environment variable fsmonitor: delay updating state until after split index is merged fsmonitor: document GIT_TRACE_FSMONITOR fsmonitor: don't bother pretty-printing JSON from watchman fsmonitor: set the PWD to the top of the working tree
2017-11-02mingw: document the standard handle redirectionJohannes Schindelin
This feature has been in Git for Windows since v2.11.0(2), as an experimental option. Now it is considered mature, and it is high time to document it properly. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2017-10-30fsmonitor: document GIT_TRACE_FSMONITORAlex Vandiver
Signed-off-by: Alex Vandiver <> Signed-off-by: Junio C Hamano <>
2017-10-17ssh: introduce a 'simple' ssh variantBrandon Williams
When using the 'ssh' transport, the '-o' option is used to specify an environment variable which should be set on the remote end. This allows git to send additional information when contacting the server, requesting the use of a different protocol version via the 'GIT_PROTOCOL' environment variable like so: "-o SendEnv=GIT_PROTOCOL". Unfortunately not all ssh variants support the sending of environment variables to the remote end. To account for this, only use the '-o' option for ssh variants which are OpenSSH compliant. This is done by checking that the basename of the ssh command is 'ssh' or the ssh variant is overridden to be 'ssh' (via the ssh.variant config). Other options like '-p' and '-P', which are used to specify a specific port to use, or '-4' and '-6', which are used to indicate that IPV4 or IPV6 addresses should be used, may also not be supported by all ssh variants. Currently if an ssh command's basename wasn't 'plink' or 'tortoiseplink' git assumes that the command is an OpenSSH variant. Since user configured ssh commands may not be OpenSSH compliant, tighten this constraint and assume a variant of 'simple' if the basename of the command doesn't match the variants known to git. The new ssh variant 'simple' will only have the host and command to execute ([username@]host command) passed as parameters to the ssh command. Update the Documentation to better reflect the command-line options sent to ssh commands based on their variant. Reported-by: Jeffrey Yasskin <> Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-10-17protocol: introduce protocol extension mechanismsBrandon Williams
Create protocol.{c,h} and provide functions which future servers and clients can use to determine which protocol to use or is being used. Also introduce the 'GIT_PROTOCOL' environment variable which will be used to communicate a colon separated list of keys with optional values to a server. Unknown keys and values must be tolerated. This mechanism is used to communicate which version of the wire protocol a client would like to use with a server. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-10-03Merge branch 'ad/doc-markup-fix'Junio C Hamano
Docfix. * ad/doc-markup-fix: doc: correct command formatting
2017-09-29doc: correct command formattingAdam Dinwoodie
Leaving spaces around the `-delimeters for commands means asciidoc fails to parse them as the start of a literal string. Remove an extraneous space that is causing a literal to not be formatted as such. Signed-off-by: Adam Dinwoodie <> Acked-by: Andreas Heiduk <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-09-27git: add --no-optional-locks optionJeff King
Some tools like IDEs or fancy editors may periodically run commands like "git status" in the background to keep track of the state of the repository. Some of these commands may refresh the index and write out the result in an opportunistic way: if they can get the index lock, then they update the on-disk index with any updates they find. And if not, then their in-core refresh is lost and just has to be recomputed by the next caller. But taking the index lock may conflict with other operations in the repository. Especially ones that the user is doing themselves, which _aren't_ opportunistic. In other words, "git status" knows how to back off when somebody else is holding the lock, but other commands don't know that status would be happy to drop the lock if somebody else wanted it. There are a couple possible solutions: 1. Have some kind of "pseudo-lock" that allows other commands to tell status that they want the lock. This is likely to be complicated and error-prone to implement (and maybe even impossible with just dotlocks to work from, as it requires some inter-process communication). 2. Avoid background runs of commands like "git status" that want to do opportunistic updates, preferring instead plumbing like diff-files, etc. This is awkward for a couple of reasons. One is that "status --porcelain" reports a lot more about the repository state than is available from individual plumbing commands. And two is that we actually _do_ want to see the refreshed index. We just don't want to take a lock or write out the result. Whereas commands like diff-files expect us to refresh the index separately and write it to disk so that they can depend on the result. But that write is exactly what we're trying to avoid. 3. Ask "status" not to lock or write the index. This is easy to implement. The big downside is that any work done in refreshing the index for such a call is lost when the process exits. So a background process may end up re-hashing a changed file multiple times until the user runs a command that does an index refresh themselves. This patch implements the option 3. The idea (and the test) is largely stolen from a Git for Windows patch by Johannes Schindelin, 67e5ce7f63 (status: offer *not* to lock the index and update it, 2016-08-12). The twist here is that instead of making this an option to "git status", it becomes a "git" option and matching environment variable. The reason there is two-fold: 1. An environment variable is carried through to sub-processes. And whether an invocation is a background process or not should apply to the whole process tree. So you could do "git --no-optional-locks foo", and if "foo" is a script or alias that calls "status", you'll still get the effect. 2. There may be other programs that want the same treatment. I've punted here on finding more callers to convert, since "status" is the obvious one to call as a repeated background job. But "git diff"'s opportunistic refresh of the index may be a good candidate. The test is taken from 67e5ce7f63, and it's worth repeating Johannes's explanation: Note that the regression test added in this commit does not *really* verify that no index.lock file was written; that test is not possible in a portable way. Instead, we verify that .git/index is rewritten *only* when `git status` is run without `--no-optional-locks`. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-10Merge branch 'ah/doc-empty-string-is-false' into maintJunio C Hamano
Doc update. * ah/doc-empty-string-is-false: doc: clarify "config --bool" behaviour with empty string
2017-08-23Merge branch 'ah/doc-empty-string-is-false'Junio C Hamano
Doc update. * ah/doc-empty-string-is-false: doc: clarify "config --bool" behaviour with empty string
2017-08-14doc: clarify "config --bool" behaviour with empty stringAndreas Heiduk
`git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in since 09bc098c2. Signed-off-by: Andreas Heiduk <> Signed-off-by: Junio C Hamano <>
2017-06-05Git 2.13.1v2.13.1Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-09Git 2.13v2.13.0Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-09Sync with v2.12.3Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Git 2.12.3v2.12.3Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.11' into maintJunio C Hamano
2017-05-05Git 2.11.2v2.11.2Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.10' into maint-2.11Junio C Hamano
2017-05-05Git 2.10.3v2.10.3Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.9' into maint-2.10Junio C Hamano
2017-05-05Git 2.9.4v2.9.4Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.8' into maint-2.9Junio C Hamano
2017-05-05Git 2.8.5v2.8.5Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.7' into maint-2.8Junio C Hamano
2017-05-05Git 2.7.5v2.7.5Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.6' into maint-2.7Junio C Hamano
2017-05-05Git 2.6.7v2.6.7Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.5' into maint-2.6Junio C Hamano
2017-05-05Git 2.5.6v2.5.6Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-05-05Merge branch 'maint-2.4' into maint-2.5Junio C Hamano
2017-05-05Git 2.4.12v2.4.12Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-03-24Sync with 2.12.2Junio C Hamano
2017-03-24Git 2.12.2v2.12.2Junio C Hamano
Signed-off-by: Junio C Hamano <>
2017-03-20Sync with 2.12.1Junio C Hamano
2017-03-20Git 2.12.1v2.12.1Junio C Hamano
Signed-off-by: Junio C Hamano <>