summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2015-09-28Git 2.6.1Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with v2.5.4Libravatar Junio C Hamano4-3/+87
2015-09-28Git 2.5.4Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.4.10Libravatar Junio C Hamano3-2/+67
2015-09-28Git 2.4.10Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.3.10Libravatar Junio C Hamano2-1/+47
2015-09-28Git 2.3.10Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Git 2.6Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25http: limit redirection to protocol-whitelistLibravatar Blake Burkhart1-5/+0
Previously, libcurl would follow redirection to any protocol it was compiled for support with. This is desirable to allow redirection from HTTP to HTTPS. However, it would even successfully allow redirection from HTTP to SFTP, a protocol that git does not otherwise support at all. Furthermore git's new protocol-whitelisting could be bypassed by following a redirect within the remote helper, as it was only enforced at transport selection time. This patch limits redirects within libcurl to HTTP, HTTPS, FTP and FTPS. If there is a protocol-whitelist present, this list is limited to those also allowed by the whitelist. As redirection happens from within libcurl, it is impossible for an HTTP redirect to a protocol implemented within another remote helper. When the curl version git was compiled with is too old to support restrictions on protocol redirection, we warn the user if GIT_ALLOW_PROTOCOL restrictions were requested. This is a little inaccurate, as even without that variable in the environment, we would still restrict SFTP, etc, and we do not warn in that case. But anything else means we would literally warn every time git accesses an http remote. This commit includes a test, but it is not as robust as we would hope. It redirects an http request to ftp, and checks that curl complained about the protocol, which means that we are relying on curl's specific error message to know what happened. Ideally we would redirect to a working ftp server and confirm that we can clone without protocol restrictions, and not with them. But we do not have a portable way of providing an ftp server, nor any other protocol that curl supports (https is the closest, but we would have to deal with certificates). [jk: added test and version warning] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-23transport: add a protocol-whitelist environment variableLibravatar Jeff King1-0/+32
If we are cloning an untrusted remote repository into a sandbox, we may also want to fetch remote submodules in order to get the complete view as intended by the other side. However, that opens us up to attacks where a malicious user gets us to clone something they would not otherwise have access to (this is not necessarily a problem by itself, but we may then act on the cloned contents in a way that exposes them to the attacker). Ideally such a setup would sandbox git entirely away from high-value items, but this is not always practical or easy to set up (e.g., OS network controls may block multiple protocols, and we would want to enable some but not others). We can help this case by providing a way to restrict particular protocols. We use a whitelist in the environment. This is more annoying to set up than a blacklist, but defaults to safety if the set of protocols git supports grows). If no whitelist is specified, we continue to default to allowing all protocols (this is an "unsafe" default, but since the minority of users will want this sandboxing effect, it is the only sensible one). A note on the tests: ideally these would all be in a single test file, but the git-daemon and httpd test infrastructure is an all-or-nothing proposition rather than a test-by-test prerequisite. By putting them all together, we would be unable to test the file-local code on machines without apache. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Update RelNotes to 2.6Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Sync with 2.5.3Libravatar Junio C Hamano2-1/+19
* maint: Git 2.5.3
2015-09-17Merge branch 'po/doc-branch-desc'Libravatar Junio C Hamano4-4/+7
The branch descriptions that are set with "git branch --edit-description" option were used in many places but they weren't clearly documented. * po/doc-branch-desc: doc: show usage of branch description
2015-09-17Merge branch 'as/config-doc-markup-fix'Libravatar Junio C Hamano1-6/+6
* as/config-doc-markup-fix: Documentation/config: fix formatting for branch.*.rebase and pull.rebase
2015-09-17Git 2.5.3Libravatar Junio C Hamano2-1/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Merge branch 'br/svn-doc-include-paths-config' into maintLibravatar Junio C Hamano1-0/+3
* br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths"
2015-09-14Update RelNotes to 2.6 to describe leftover bits since -rc2Libravatar Junio C Hamano1-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-14Git 2.6-rc2Libravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-14doc: show usage of branch descriptionLibravatar Philip Oakley4-4/+7
The branch description will be included in 'git format-patch --cover-letter' and in 'git pull-request' emails. It can also be used in the automatic merge message. Tell the reader. While here, clarify that the description may be a multi-line explanation of the purpose of the branch's patch series. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-14Merge branch 'jk/pack-protocol-doc'Libravatar Junio C Hamano2-21/+30
Streamline documentation of the pkt-line protocol. * jk/pack-protocol-doc: pack-protocol: clarify LF-handling in PKT-LINE()
2015-09-12Documentation/config: fix formatting for branch.*.rebase and pull.rebaseLibravatar Andreas Schwab1-6/+6
Don't format the second paragraph as a literal block. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-09Sync with 2.5.2Libravatar Junio C Hamano5-4/+98
2015-09-09Release Notes: typofixLibravatar Junio C Hamano1-1/+1
Thanks to Andreas Schwab for careful reading. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Git 2.5.2Libravatar Junio C Hamano2-1/+65
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.4.9Libravatar Junio C Hamano4-3/+33
2015-09-04Git 2.4.9Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.3.9Libravatar Junio C Hamano3-2/+22
2015-09-04Git 2.3.9Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.2.3Libravatar Junio C Hamano2-1/+11
2015-09-04Git 2.2.3Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03Merge branch 'as/docfix-reflog-expire-unreachable' into maintLibravatar Junio C Hamano1-1/+1
Docfix. * as/docfix-reflog-expire-unreachable: Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable
2015-09-03Merge branch 'jk/rev-list-has-no-notes' into maintLibravatar Junio C Hamano3-0/+6
"git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes
2015-09-03pack-protocol: clarify LF-handling in PKT-LINE()Libravatar Jeff King2-21/+30
The spec is very inconsistent about which PKT-LINE() parts of the grammar include a LF. On top of that, the code is not consistent, either (e.g., send-pack does not put newlines into the ref-update commands it sends). Let's make explicit the long-standing expectation that we generally expect pkt-lines to end in a newline, but that receivers should be lenient. This makes the spec consistent, and matches what git already does (though it does not always fulfill the SHOULD). We do make an exception for the push-cert, where the receiving code is currently a bit pickier. This is a reasonable way to be, as the data needs to be byte-for-byte compatible with what was signed. We _could_ make up some rules about signing a canonicalized version including newlines, but that would require a code change, and is out of scope for this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02Git 2.6-rc0Libravatar Junio C Hamano1-3/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01Ninth batch for 2.6Libravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01Merge branch 'br/svn-doc-include-paths-config'Libravatar Junio C Hamano1-0/+3
* br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths"
2015-08-31Eighth batch for 2.6Libravatar Junio C Hamano1-0/+39
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31Merge branch 'sg/describe-contains'Libravatar Junio C Hamano1-2/+2
"git describe" without argument defaulted to describe the HEAD commit, but "git describe --contains" didn't. Arguably, in a repository used for active development, such defaulting would not be very useful as the tip of branch is typically not tagged, but it is better to be consistent. * sg/describe-contains: describe --contains: default to HEAD when no commit-ish is given
2015-08-31Merge branch 'db/push-sign-if-asked'Libravatar Junio C Hamano4-6/+36
The client side codepaths in "git push" have been cleaned up and the user can request to perform an optional "signed push", i.e. sign only when the other end accepts signed push. * db/push-sign-if-asked: push: add a config option push.gpgSign for default signed pushes push: support signing pushes iff the server supports it builtin/send-pack.c: use parse_options API config.c: rename git_config_maybe_bool_text and export it as git_parse_maybe_bool transport: remove git_transport_options.push_cert gitremote-helpers.txt: document pushcert option Documentation/git-send-pack.txt: document --signed Documentation/git-send-pack.txt: wrap long synopsis line Documentation/git-push.txt: document when --signed may fail
2015-08-31Merge branch 'jk/notes-merge-config'Libravatar Junio C Hamano2-5/+36
"git notes merge" can be told with "--strategy=<how>" option how to automatically handle conflicts; this can now be configured by setting notes.mergeStrategy configuration variable. * jk/notes-merge-config: notes: teach git-notes about notes.<name>.mergeStrategy option notes: add notes.mergeStrategy option to select default strategy notes: add tests for --commit/--abort/--strategy exclusivity notes: extract parse_notes_merge_strategy to notes-utils notes: extract enum notes_merge_strategy to notes-utils.h notes: document cat_sort_uniq rewriteMode
2015-08-31Merge branch 'jk/rev-list-has-no-notes'Libravatar Junio C Hamano3-0/+6
"git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes
2015-08-31Merge branch 'hv/submodule-config'Libravatar Junio C Hamano1-0/+62
The gitmodules API accessed from the C code learned to cache stuff lazily. * hv/submodule-config: submodule: allow erroneous values for the fetchRecurseSubmodules option submodule: use new config API for worktree configurations submodule: extract functions for config set and lookup submodule: implement a config API for lookup of .gitmodules values
2015-08-31Merge branch 'sg/config-name-only'Libravatar Junio C Hamano1-3/+7
"git config --list" output was hard to parse when values consist of multiple lines. "--name-only" option is added to help this. * sg/config-name-only: get_urlmatch: avoid useless strbuf write format_config: simplify buffer handling format_config: don't init strbuf config: restructure format_config() for better control flow completion: list variable names reliably with 'git config --name-only' config: add '--name-only' option to list only variable names
2015-08-28Sync with 2.5.1Libravatar Junio C Hamano2-1/+18
2015-08-28Seventh batch for 2.6Libravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28Git 2.5.1Libravatar Junio C Hamano2-1/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-26Sixth batch for 2.6Libravatar Junio C Hamano1-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-26Merge branch 'as/docfix-reflog-expire-unreachable'Libravatar Junio C Hamano1-1/+1
* as/docfix-reflog-expire-unreachable: Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable
2015-08-26Merge branch 'jv/send-email-selective-smtp-auth'Libravatar Junio C Hamano1-0/+13
"git send-email" learned a new option --smtp-auth to limit the SMTP AUTH mechanisms to be used to a subset of what the system library supports. * jv/send-email-selective-smtp-auth: send-email: provide whitelist of SMTP AUTH mechanisms
2015-08-26Merge branch 'ep/http-configure-ssl-version'Libravatar Junio C Hamano1-0/+23
A new configuration variable http.sslVersion can be used to specify what specific version of SSL/TLS to use to make a connection. * ep/http-configure-ssl-version: http: add support for specifying the SSL version