summaryrefslogtreecommitdiff
path: root/Documentation
Commit message (Collapse)AuthorAgeFilesLines
* Documentation/diff: give --word-diff-regex=. examplemg/doc-word-diff-exampleMichael J Gruber2015-11-241-0/+3
| | | | | | | It's just so useful. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net>
* Documentation/git-update-index: add missing opts to synopsysChristian Couder2015-11-241-0/+1
| | | | | | | Untracked cache related options should appear in the synopsis. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Jeff King <peff@peff.net>
* Git 2.6.3v2.6.3Junio C Hamano2015-11-052-1/+113
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rs/daemon-plug-child-leak' into maintJunio C Hamano2015-11-051-0/+7
|\ | | | | | | | | | | | | | | | | "git daemon" uses "run_command()" without "finish_command()", so it needs to release resources itself, which it forgot to do. * rs/daemon-plug-child-leak: daemon: plug memory leak run-command: factor out child_process_clear()
| * run-command: factor out child_process_clear()René Scharfe2015-11-021-0/+7
| | | | | | | | | | | | | | | | | | Avoid duplication by moving the code to release allocated memory for arguments and environment to its own function, child_process_clear(). Export it to provide a counterpart to child_process_init(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'xf/user-manual-ff' into maintJunio C Hamano2015-11-041-5/+5
|\ \ | | | | | | | | | | | | * xf/user-manual-ff: user-manual: fix the description of fast-forward
| * | user-manual: fix the description of fast-forwardxf/user-manual-ffXue Fuqiao2015-10-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The "Fast-forward merges" section of user-manual.txt incorrectly says if the current branch is a descendant of the other, Git will perform a fast-forward merge, but it should the other way around. Signed-off-by: Xue Fuqiao <xfq.free@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'xf/user-manual-markup' into maintJunio C Hamano2015-11-0411-11/+11
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AsciiDoc markup fixes. * xf/user-manual-markup: Documentation: match undefline with the text in old release notes Documentation: match underline with the text Documentation: fix header markup
| * | | Documentation: match undefline with the text in old release notesxf/user-manual-markupJunio C Hamano2015-10-225-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These are not processed with AsciiDoc, but it is better to be consistent. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation: match underline with the textJunio C Hamano2015-10-225-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though AsciiDoc is more lenient when deciding if an underline is for the contents on the previous line to find section headers, we should match the length of them for other formatters to help them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation: fix header markupXue Fuqiao2015-10-221-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Asciidoctor is stricter than AsciiDoc when deciding if underlining is a section title or the start of preformatted text. Make the length of the underlining match the text to ensure that it renders correctly in all implementations. Signed-off-by: Xue Fuqiao <xfq.free@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/everyday-markup' into maintJunio C Hamano2015-11-041-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | AsciiDoc markup fixes. * jc/everyday-markup: Documentation/everyday: match undefline with the text
| * | | Documentation/everyday: match undefline with the textjc/everyday-markupJunio C Hamano2015-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though AsciiDoc is more lenient when deciding if an underline is for the contents on the previous line to find section headers, we should match the length of them for other formatters to help them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/em-dash-in-doc' into maintJunio C Hamano2015-11-046-6/+6
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AsciiDoc markup fixes. * jc/em-dash-in-doc: Documentation: AsciiDoc spells em-dash as double-dashes, not triple
| * | | | Documentation: AsciiDoc spells em-dash as double-dashes, not triplejc/em-dash-in-docJunio C Hamano2015-10-226-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again, we do not usually process release notes with AsciiDoc, but it is better to be consistent. This incidentally reveals breakages left by an ancient 5e00439f (Documentation: build html for all files in technical and howto, 2012-10-23). The index-format documentation was originally written to be read as straight text without formatting and when the commit forced everything in Documentation/ to go through AsciiDoc, it did not do any adjustment--hence the double-dashes will be seen in the resulting text that is rendered as preformatted fixed-width without converted into em-dashes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/merge-file-exit-code' into maintJunio C Hamano2015-11-031-1/+2
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git merge-file" tried to signal how many conflicts it found, which obviously would not work well when there are too many of them. * jk/merge-file-exit-code: merge-file: clamp exit code to maximum 127
| * | | | | merge-file: clamp exit code to maximum 127jk/merge-file-exit-codeJeff King2015-10-291-1/+2
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Git-merge-file is documented to return one of three exit codes: - zero means the merge was successful - a negative number means an error occurred - a positive number indicates the number of conflicts Unfortunately, this all gets stuffed into an 8-bit return code. Which means that if you have 256 conflicts, this wraps to zero, and the merge appears to succeed (and commits a blob full of conflict-marker cruft!). This patch clamps the return value to a maximum of 127, which we should be able to safely represent everywhere. This also leaves 128-255 for other values. Shells (and some parts of git) will typically represent signal death as 128 plus the signal number. And negative values are typically coerced to an 8-bit unsigned value (so "return -1" ends up as 255). Technically negative returns have the same problem (e.g., "-256" wraps back to 0), but this is not a problem in practice, as the only negative value we use is "-1". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jc/usage-stdin' into maintJunio C Hamano2015-11-0313-28/+51
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The synopsis text and the usage string of subcommands that read list of things from the standard input are often shown as if they only take input from a file on a filesystem, which was misleading. * jc/usage-stdin: usage: do not insist that standard input must come from a file
| * | | | | usage: do not insist that standard input must come from a filejc/usage-stdinJunio C Hamano2015-10-1613-28/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The synopsys text and the usage string of subcommands that read list of things from the standard input are often shown like this: git gostak [--distim] < <list-of-doshes> This is problematic in a number of ways: * The way to use these commands is more often to feed them the output from another command, not feed them from a file. * Manual pages outside Git, commands that operate on the data read from the standard input, e.g "sort", "grep", "sed", etc., are not described with such a "< redirection-from-file" in their synopsys text. Our doing so introduces inconsistency. * We do not insist on where the output should go, by saying git gostak [--distim] < <list-of-doshes> > <output> * As it is our convention to enclose placeholders inside <braket>, the redirection operator followed by a placeholder filename becomes very hard to read, both in the documentation and in the help text. Let's clean them all up, after making sure that the documentation clearly describes the modes that take information from the standard input and what kind of things are expected on the input. [jc: stole example for fmt-merge-msg from Jonathan] Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'jk/repository-extension' into maintJunio C Hamano2015-11-031-0/+88
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prepare for Git on-disk repository representation to undergo backward incompatible changes by introducing a new repository format version "1", with an extension mechanism. * jk/repository-extension: introduce "preciousObjects" repository extension introduce "extensions" form of core.repositoryformatversion
| * | | | | | introduce "preciousObjects" repository extensionjk/repository-extensionJeff King2015-06-241-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If this extension is used in a repository, then no operations should run which may drop objects from the object storage. This can be useful if you are sharing that storage with other repositories whose refs you cannot see. For instance, if you do: $ git clone -s parent child $ git -C parent config extensions.preciousObjects true $ git -C parent config core.repositoryformatversion 1 you now have additional safety when running git in the parent repository. Prunes and repacks will bail with an error, and `git gc` will skip those operations (it will continue to pack refs and do other non-object operations). Older versions of git, when run in the repository, will fail on every operation. Note that we do not set the preciousObjects extension by default when doing a "clone -s", as doing so breaks backwards compatibility. It is a decision the user should make explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | introduce "extensions" form of core.repositoryformatversionJeff King2015-06-241-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally we try to avoid bumps of the whole-repository core.repositoryformatversion field. However, it is unavoidable if we want to safely change certain aspects of git in a backwards-incompatible way (e.g., modifying the set of ref tips that we must traverse to generate a list of unreachable, safe-to-prune objects). If we were to bump the repository version for every such change, then any implementation understanding version `X` would also have to understand `X-1`, `X-2`, and so forth, even though the incompatibilities may be in orthogonal parts of the system, and there is otherwise no reason we cannot implement one without the other (or more importantly, that the user cannot choose to use one feature without the other, weighing the tradeoff in compatibility only for that particular feature). This patch documents the existing repositoryformatversion strategy and introduces a new format, "1", which lets a repository specify that it must run with an arbitrary set of extensions. This can be used, for example: - to inform git that the objects should not be pruned based only on the reachability of the ref tips (e.g, because it has "clone --shared" children) - that the refs are stored in a format besides the usual "refs" and "packed-refs" directories Because we bump to format "1", and because format "1" requires that a running git knows about any extensions mentioned, we know that older versions of the code will not do something dangerous when confronted with these new formats. For example, if the user chooses to use database storage for refs, they may set the "extensions.refbackend" config to "db". Older versions of git will not understand format "1" and bail. Versions of git which understand "1" but do not know about "refbackend", or which know about "refbackend" but not about the "db" backend, will refuse to run. This is annoying, of course, but much better than the alternative of claiming that there are no refs in the repository, or writing to a location that other implementations will not read. Note that we are only defining the rules for format 1 here. We do not ever write format 1 ourselves; it is a tool that is meant to be used by users and future extensions to provide safety with older implementations. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'jc/doc-gc-prune-now' into maintJunio C Hamano2015-10-201-2/+5
|\ \ \ \ \ \ \ | |_|/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git gc" is safe to run anytime only because it has the built-in grace period to protect young objects. In order to run with no grace period, the user must make sure that the repository is quiescent. * jc/doc-gc-prune-now: Documentation/gc: warn against --prune=<now>
| * | | | | | Documentation/gc: warn against --prune=<now>jc/doc-gc-prune-nowJunio C Hamano2015-10-141-2/+5
| | |_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git gc" is safe to run anytime only because it has the built-in grace period to protect objects that are created by other processes that are waiting for ref updates to anchor them to the history. In order to run with no grace period, the user must make sure that the repository is quiescent. Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Git 2.6.2v2.6.2Junio C Hamano2015-10-162-1/+67
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'tk/doc-interpret-trailers-grammo' into maintJunio C Hamano2015-10-161-1/+1
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * tk/doc-interpret-trailers-grammo: Documentation/interpret-trailers: Grammar fix
| * | | | | | Documentation/interpret-trailers: Grammar fixtk/doc-interpret-trailers-grammoTobias Klauser2015-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'jk/asciidoctor-section-heading-markup-fix' into maintJunio C Hamano2015-10-162-2/+2
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/asciidoctor-section-heading-markup-fix: Documentation: fix section header mark-up
| * | | | | | | Documentation: fix section header mark-upjk/asciidoctor-section-heading-markup-fixJohn Keeping2015-09-252-2/+2
| | |_|_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Asciidoctor is stricter than AsciiDoc when deciding if underlining is a section title or the start of preformatted text. Make the length of the underlining match the text to ensure that it renders correctly in all implementations. Signed-off-by: John Keeping <john@keeping.me.uk> [jc: squashed in git-bisect one noticed by Michael J Gruber] Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'nd/ls-remote-does-not-have-u-option' into maintJunio C Hamano2015-10-161-2/+1
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * nd/ls-remote-does-not-have-u-option: ls-remote.txt: delete unsupported option
| * | | | | | | ls-remote.txt: delete unsupported optionnd/ls-remote-does-not-have-u-optionNguyễn Thái Ngọc Duy2015-09-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -u <exec> has never been supported, but it was mentioned since 0a2bb55 (git ls-remote: make usage string match manpage - 2008-11-11). Nobody has complained about it for seven years, it's probably safe to say nobody cares. So let's remove "-u" in documents instead of adding code to support it. While at there, fix --upload-pack syntax too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | Merge branch 'dt/log-follow-config' into maintJunio C Hamano2015-10-162-4/+10
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Description of the "log.follow" configuration variable in "git log" documentation is now also copied to "git config" documentation. * dt/log-follow-config: log: Update log.follow doc and add to config.txt
| * | | | | | | | log: Update log.follow doc and add to config.txtdt/log-follow-configEric N. Vander Weele2015-10-072-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation/config.txt does not include the documentation for log.follow that is in Documentation/git-log.txt. This commit adds the log.follow documentation to config.txt and also updates the wording to be consistent with the format that is followed by other boolean configuration variables. Signed-off-by: Eric N. Vander Weele <ericvw@gmail.com> Acked-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | Merge branch 'jk/notes-dwim-doc' into maintJunio C Hamano2015-10-162-3/+6
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way how --ref/--notes to specify the notes tree reference are DWIMmed was not clearly documented. * jk/notes-dwim-doc: notes: correct documentation of DWIMery for notes references
| * | | | | | | | | notes: correct documentation of DWIMery for notes referencesjk/notes-dwim-docJacob Keller2015-09-222-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expand_notes_ref is used by --ref from git-notes(1) and --notes from the git log to find the full refname of a notes reference. Previously the documentation of these options was not clear about what sorts of expansions would be performed. Fix the documentation to clearly and accurately describe the behavior of the expansions. Add a test for this expansion when using git notes get-ref in order to prevent future patches from changing this behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | Merge branch 'mm/keyid-docs' into maintJunio C Hamano2015-10-1610-29/+47
|\ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Very small number of options take a parameter that is optional (which is not a great UI element as they can only appear at the end of the command line). Add notice to documentation of each and every one of them. * mm/keyid-docs: Documentation: explain optional arguments better Documentation/grep: fix documentation of -O Documentation: use 'keyid' consistently, not 'key-id'
| * | | | | | | | | | Documentation: explain optional arguments bettermm/keyid-docsMatthieu Moy2015-09-219-10/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | | | | Documentation/grep: fix documentation of -OMatthieu Moy2015-09-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the argument of -O, --open-file-in-pager is optional, it must be stuck to the command. Reflect this in the documentation. 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>
| * | | | | | | | | | Documentation: use 'keyid' consistently, not 'key-id'Matthieu Moy2015-09-215-17/+17
| |/ / / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | | | | Git 2.6.1v2.6.1Junio C Hamano2015-09-282-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | Sync with v2.5.4Junio C Hamano2015-09-284-3/+87
|\ \ \ \ \ \ \ \ \ \
| * | | | | | | | | | Git 2.5.4v2.5.4Junio C Hamano2015-09-282-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | | Sync with 2.4.10Junio C Hamano2015-09-283-2/+67
| |\ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / | |/| | | | | | | | / | | | |_|_|_|_|_|_|/ | | |/| | | | | | |
| | * | | | | | | | Git 2.4.10v2.4.10Junio C Hamano2015-09-282-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| | * | | | | | | | Sync with 2.3.10Junio C Hamano2015-09-282-1/+47
| | |\ \ \ \ \ \ \ \ | | | |_|/ / / / / / | | |/| | | | | | |
| | | * | | | | | | Git 2.3.10v2.3.10maint-2.3Junio C Hamano2015-09-282-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| | | * | | | | | | http: limit redirection to protocol-whitelistBlake Burkhart2015-09-251-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>
| | | * | | | | | | transport: add a protocol-whitelist environment variableJeff King2015-09-231-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>
* | | | | | | | | | Git 2.6v2.6.0Junio C Hamano2015-09-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | Update RelNotes to 2.6Junio C Hamano2015-09-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>