summaryrefslogtreecommitdiff
path: root/Documentation/git.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-09-29doc: correct command formattingLibravatar Adam Dinwoodie1-1/+1
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 <adam@dinwoodie.org> Acked-by: Andreas Heiduk <asheiduk@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-10Merge branch 'ah/doc-empty-string-is-false' into maintLibravatar Junio C Hamano1-1/+2
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 stringLibravatar Andreas Heiduk1-1/+2
`git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in t1300-repo-config.sh since 09bc098c2. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-05Git 2.13.1Libravatar Junio C Hamano1-510/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09Git 2.13Libravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-08Sync with v2.12.3Libravatar Junio C Hamano1-10/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Git 2.12.3Libravatar Junio C Hamano1-3/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.11' into maintLibravatar Junio C Hamano1-7/+16
2017-05-05Git 2.11.2Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.10' into maint-2.11Libravatar Junio C Hamano1-7/+15
2017-05-05Git 2.10.3Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.9' into maint-2.10Libravatar Junio C Hamano1-6/+13
2017-05-05Git 2.9.4Libravatar Junio C Hamano1-1/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.8' into maint-2.9Libravatar Junio C Hamano1-5/+11
2017-05-05Git 2.8.5Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.7' into maint-2.8Libravatar Junio C Hamano1-4/+9
2017-05-05Git 2.7.5Libravatar Junio C Hamano1-1/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.6' into maint-2.7Libravatar Junio C Hamano1-3/+6
2017-05-05Git 2.6.7Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.5' into maint-2.6Libravatar Junio C Hamano1-2/+4
2017-05-05Git 2.5.6Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.4' into maint-2.5Libravatar Junio C Hamano1-1/+2
2017-05-05Git 2.4.12Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24Sync with 2.12.2Libravatar Junio C Hamano1-1/+2
2017-03-24Git 2.12.2Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-20Sync with 2.12.1Libravatar Junio C Hamano1-1/+2
2017-03-20Git 2.12.1Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'sf/putty-w-args'Libravatar Junio C Hamano1-0/+6
The command line options for ssh invocation needs to be tweaked for some implementations of SSH (e.g. PuTTY plink wants "-P <port>" while OpenSSH wants "-p <port>" to specify port to connect to), and the variant was guessed when GIT_SSH environment variable is used to specify it. The logic to guess now applies to the command specified by the newer GIT_SSH_COMMAND and also core.sshcommand configuration variable, and comes with an escape hatch for users to deal with misdetected cases. * sf/putty-w-args: connect.c: stop conflating ssh command names and overrides connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config git_connect(): factor out SSH variant handling connect: rename tortoiseplink and putty variables connect: handle putty/plink also in GIT_SSH_COMMAND
2017-02-24Git 2.12Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01connect: Add the envvar GIT_SSH_VARIANT and ssh.variant configLibravatar Segev Finer1-0/+6
This environment variable and configuration value allow to override the autodetection of plink/tortoiseplink in case that Git gets it wrong. [jes: wrapped overly-long lines, factored out and changed get_ssh_variant() to handle_ssh_variant() to accomodate the change from the putty/tortoiseplink variables to port_option/needs_batch, adjusted the documentation, free()d value obtained from the config.] Signed-off-by: Segev Finer <segev208@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
2017-01-17Almost ready for 2.11.1Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17Merge branch 'jk/quote-env-path-list-component' into maintLibravatar Junio C Hamano1-0/+6
A recent update to receive-pack to make it easier to drop garbage objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot have a pathname with a colon in it (no surprise!), and this in turn made it impossible to push into a repository at such a path. This has been fixed by introducing a quoting mechanism used when appending such a path to the colon-separated list. * jk/quote-env-path-list-component: t5615-alternate-env: double-quotes in file names do not work on Windows t5547-push-quarantine: run the path separator test on Windows, too tmp-objdir: quote paths we add to alternates alternates: accept double-quoted paths
2016-12-27Merge branch 'bw/transport-protocol-policy'Libravatar Junio C Hamano1-24/+14
Finer-grained control of what protocols are allowed for transports during clone/fetch/push have been enabled via a new configuration mechanism. * bw/transport-protocol-policy: http: respect protocol.*.allow=user for http-alternates transport: add from_user parameter to is_transport_allowed http: create function to get curl allowed protocols transport: add protocol policy config option http: always warn if libcurl version is too old lib-proto-disable: variable name fix
2016-12-21Merge branch 'jk/quote-env-path-list-component'Libravatar Junio C Hamano1-0/+6
A recent update to receive-pack to make it easier to drop garbage objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot have a pathname with a colon in it (no surprise!), and this in turn made it impossible to push into a repository at such a path. This has been fixed by introducing a quoting mechanism used when appending such a path to the colon-separated list. * jk/quote-env-path-list-component: t5615-alternate-env: double-quotes in file names do not work on Windows t5547-push-quarantine: run the path separator test on Windows, too tmp-objdir: quote paths we add to alternates alternates: accept double-quoted paths
2016-12-15transport: add protocol policy config optionLibravatar Brandon Williams1-24/+14
Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/push commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of allowing easier construction of a protocol whitelist on systems where setting an environment variable is non-trivial. Now users can specify a policy to be used for each type of protocol via the 'protocol.<name>.allow' config option. A default policy for all unconfigured protocols can be set with the 'protocol.allow' config option. If no user configured default is made git will allow known-safe protocols (http, https, git, ssh, file), disallow known-dangerous protocols (ext), and have a default policy of `user` for all other protocols. The supported policies are `always`, `never`, and `user`. The `user` policy can be used to configure a protocol to be usable when explicitly used by a user, while disallowing it for commands which run clone/fetch/push commands without direct user intervention (e.g. recursive initialization of submodules). Commands which can potentially clone/fetch/push from untrusted repositories without user intervention can export `GIT_PROTOCOL_FROM_USER` with a value of '0' to prevent protocols configured to the `user` policy from being used. Fix remote-ext tests to use the new config to allow the ext protocol to be tested. Based on a patch by Jeff King <peff@peff.net> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12alternates: accept double-quoted pathsLibravatar Jeff King1-0/+6
We read lists of alternates from objects/info/alternates files (delimited by newline), as well as from the GIT_ALTERNATE_OBJECT_DIRECTORIES environment variable (delimited by colon or semi-colon, depending on the platform). There's no mechanism for quoting the delimiters, so it's impossible to specify an alternate path that contains a colon in the environment, or one that contains a newline in a file. We've lived with that restriction for ages because both alternates and filenames with colons are relatively rare, and it's only a problem when the two meet. But since 722ff7f87 (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03), which builds on the alternates system, every push causes the receiver to set GIT_ALTERNATE_OBJECT_DIRECTORIES internally. It would be convenient to have some way to quote the delimiter so that we can represent arbitrary paths. The simplest thing would be an escape character before a quoted delimiter (e.g., "\:" as a literal colon). But that creates a backwards compatibility problem: any path which uses that escape character is now broken, and we've just shifted the problem. We could choose an unlikely escape character (e.g., something from the non-printable ASCII range), but that's awkward to use. Instead, let's treat names as unquoted unless they begin with a double-quote, in which case they are interpreted via our usual C-stylke quoting rules. This also breaks backwards-compatibility, but in a smaller way: it only matters if your file has a double-quote as the very _first_ character in the path (whereas an escape character is a problem anywhere in the path). It's also consistent with many other parts of git, which accept either a bare pathname or a double-quoted one, and the sender can choose to quote or not as required. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29Git 2.11Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Sync with 2.10.2Libravatar Junio C Hamano1-1/+2
2016-10-28Git 2.10.2Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Merge branch 'bw/ls-files-recurse-submodules'Libravatar Junio C Hamano1-0/+6
"git ls-files" learned "--recurse-submodules" option that can be used to get a listing of tracked files across submodules (i.e. this only works with "--cached" option, not for listing untracked or ignored files). This would be a useful tool to sit on the upstream side of a pipe that is read with xargs to work on all working tree files from the top-level superproject. * bw/ls-files-recurse-submodules: ls-files: add pathspec matching for submodules ls-files: pass through safe options for --recurse-submodules ls-files: optionally recurse into submodules git: make super-prefix option
2016-10-10git: make super-prefix optionLibravatar Brandon Williams1-0/+6
Add a super-prefix environment variable 'GIT_INTERNAL_SUPER_PREFIX' which can be used to specify a path from above a repository down to its root. When such a super-prefix is specified, the paths reported by Git are prefixed with it to make them relative to that directory "above". The paths given by the user on the command line (e.g. "git subcmd --output-file=path/to/a/file" and pathspecs) are taken relative to the directory "above" to match. The immediate use of this option is by commands which have a --recurse-submodule option in order to give context to submodules about how they were invoked. This option is currently only allowed for builtins which support a super-prefix. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-03Git 2.10.1Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-02Git 2.10Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12Sync with 2.9.3Libravatar Junio C Hamano1-1/+2
* tag 'v2.9.3': Git 2.9.3
2016-08-12Git 2.9.3Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'mm/doc-tt' into maintLibravatar Junio C Hamano1-5/+5
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-07-15Sync with 2.9.2Libravatar Junio C Hamano1-1/+2
* maint: Git 2.9.2 t0006: skip "far in the future" test when unsigned long is not long enough
2016-07-15Git 2.9.2Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'mm/doc-tt'Libravatar Junio C Hamano1-5/+5
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 11:33:49 +0000