summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-16Merge branch 'jk/make-findstring-makeflags-fix' into maintLibravatar Junio C Hamano1-2/+2
Customization to change the behaviour with "make -w" and "make -s" in our Makefile was broken when they were used together. * jk/make-findstring-makeflags-fix: Makefile: fix MAKEFLAGS tests with multiple flags
2015-10-16Merge branch 'jw/make-arflags-customizable' into maintLibravatar Junio C Hamano1-3/+6
The Makefile always runs the library archiver with hardcoded "crs" options, which was inconvenient for exotic platforms on which people want to use programs with totally different set of command line options. * jw/make-arflags-customizable: Makefile: allow $(ARFLAGS) specified from the command line
2015-10-16Merge branch 'jk/connect-clear-env' into maintLibravatar Junio C Hamano2-10/+49
The ssh transport, just like any other transport over the network, did not clear GIT_* environment variables, but it is possible to use SendEnv and AcceptEnv to leak them to the remote invocation of Git, which is not a good idea at all. Explicitly clear them just like we do for the local transport. * jk/connect-clear-env: git_connect: clarify conn->use_shell flag git_connect: clear GIT_* environment for ssh
2015-10-16Merge branch 'jk/blame-first-parent' into maintLibravatar Junio C Hamano2-1/+14
"git blame --first-parent v1.0..v2.0" was not rejected but did not limit the blame to commits on the first parent chain. * jk/blame-first-parent: blame: handle --first-parent
2015-10-16Merge branch 'mm/keyid-docs' into maintLibravatar Junio C Hamano10-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'
2015-10-16Merge branch 'pt/pull-builtin' into maintLibravatar Junio C Hamano3-3/+3
* pt/pull-builtin: pull: enclose <options> in brackets in the usage string merge: grammofix in please-commit-before-merge message
2015-10-16pull: enclose <options> in brackets in the usage stringLibravatar Alex Henrie1-1/+1
All the other placeholders are already shown that way. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02merge: grammofix in please-commit-before-merge messageLibravatar Alex Henrie2-2/+2
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Git 2.6.1Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with v2.5.4Libravatar Junio C Hamano29-30/+486
2015-09-28Git 2.5.4Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.4.10Libravatar Junio C Hamano28-29/+466
2015-09-28Git 2.4.10Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.3.10Libravatar Junio C Hamano27-28/+446
2015-09-28Git 2.3.10Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Merge branch 'jk/xdiff-memory-limits' into maint-2.3Libravatar Junio C Hamano11-26/+57
2015-09-28merge-file: enforce MAX_XDIFF_SIZE on incoming filesLibravatar Jeff King1-1/+2
The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28xdiff: reject files larger than ~1GBLibravatar Jeff King3-1/+14
The xdiff code is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in our input files. This can cause us to produce incorrect diffs, with no indication that the output is wrong. Or worse, we may even underallocate a buffer whose size is the result of an overflowing addition. We're much better off to tell the user that we cannot diff or merge such a large file. This patch covers both cases, but in slightly different ways: 1. For merging, we notice the large file and cleanly fall back to a binary merge (which is effectively "we cannot merge this"). 2. For diffing, we make the binary/text distinction much earlier, and in many different places. For this case, we'll use the xdi_diff as our choke point, and reject any diff there before it hits the xdiff code. This means in most cases we'll die() immediately after. That's not ideal, but in practice we shouldn't generally hit this code path unless the user is trying to do something tricky. We already consider files larger than core.bigfilethreshold to be binary, so this code would only kick in when that is circumvented (either by bumping that value, or by using a .gitattribute to mark a file as diffable). In other words, we can avoid being "nice" here, because there is already nice code that tries to do the right thing. We are adding the suspenders to the nice code's belt, so notice when it has been worked around (both to protect the user from malicious inputs, and because it is better to die() than generate bogus output). The maximum size was chosen after experimenting with feeding large files to the xdiff code. It's just under a gigabyte, which leaves room for two obvious cases: - a diff3 merge conflict result on files of maximum size X could be 3*X plus the size of the markers, which would still be only about 3G, which fits in a 32-bit int. - some of the diff code allocates arrays of one int per record. Even if each file consists only of blank lines, then a file smaller than 1G will have fewer than 1G records, and therefore the int array will fit in 4G. Since the limit is arbitrary anyway, I chose to go under a gigabyte, to leave a safety margin (e.g., we would not want to overflow by allocating "(records + 1) * sizeof(int)" or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28react to errors in xdi_diffLibravatar Jeff King7-24/+41
When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Merge branch 'jk/transfer-limit-redirection' into maint-2.3Libravatar Junio C Hamano6-15/+78
2015-09-28Merge branch 'jk/transfer-limit-protocol' into maint-2.3Libravatar Junio C Hamano13-1/+306
2015-09-28Git 2.6Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25http: limit redirection depthLibravatar Blake Burkhart3-0/+8
By default, libcurl will follow circular http redirects forever. Let's put a cap on this so that somebody who can trigger an automated fetch of an arbitrary repository (e.g., for CI) cannot convince git to loop infinitely. The value chosen is 20, which is the same default that Firefox uses. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25http: limit redirection to protocol-whitelistLibravatar Blake Burkhart4-5/+27
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-25transport: refactor protocol whitelist codeLibravatar Jeff King2-10/+43
The current callers only want to die when their transport is prohibited. But future callers want to query the mechanism without dying. Let's break out a few query functions, and also save the results in a static list so we don't have to re-parse for each query. Based-on-a-patch-by: Blake Burkhart <bburky@bburky.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-23submodule: allow only certain protocols for submodule fetchesLibravatar Jeff King2-0/+52
Some protocols (like git-remote-ext) can execute arbitrary code found in the URL. The URLs that submodules use may come from arbitrary sources (e.g., .gitmodules files in a remote repository). Let's restrict submodules to fetching from a known-good subset of protocols. Note that we apply this restriction to all submodule commands, whether the URL comes from .gitmodules or not. This is more restrictive than we need to be; for example, in the tests we run: git submodule add ext::... which should be trusted, as the URL comes directly from the command line provided by the user. But doing it this way is simpler, and makes it much less likely that we would miss a case. And since such protocols should be an exception (especially because nobody who clones from them will be able to update the submodules!), it's not likely to inconvenience anyone in practice. Reported-by: Blake Burkhart <bburky@bburky.com> 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 King11-1/+254
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-21Git 2.6-rc3Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-21Merge branch 'rj/mailmap-ramsay'Libravatar Junio C Hamano1-1/+1
* rj/mailmap-ramsay: mailmap: update my entry with new email address
2015-09-21Merge branch 'bn/send-email-smtp-auth-error-message-fix'Libravatar Junio C Hamano1-1/+1
Fix a minor regression brought in to "git send-email" by a recent addition of the "--smtp-auth" option. * bn/send-email-smtp-auth-error-message-fix: send-email: fix uninitialized var warning for $smtp_auth
2015-09-21Merge tag 'l10n-2.6.0-rnd2+de' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano8-11681/+14967
l10n-2.6.0-rnd2 plus de * tag 'l10n-2.6.0-rnd2+de' of git://github.com/git-l10n/git-po: (25 commits) l10n: de.po: better language for one string l10n: de.po: translate 2 messages l10n: Update and review Vietnamese translation (2440t) l10n: fr.po v2.6.0 round 2 (2440t) l10n: zh_CN: for git v2.6.0 l10n round 2 l10n: ca.po: update translation l10n: git.pot: v2.6.0 round 2 (3 improvements) l10n: de.po: translate 123 new messages l10n: fr.po v2.6.0 round 1 (2441t) l10n: sv.po: Update Swedish translation (2441t0f0u) l10n: zh_CN: for git v2.6.0 l10n round 1 l10n: Updated Vietnamese translation (2441t) l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed) l10n: zh_CN: Update Git Glossary: "commit message" l10n: zh_CN: Update Git Glossary: pickaxe l10n: zh_CN: Update Git Glossary: fork l10n: zh_CN: Update Git Glossary: tag l10n: zh_CN: Update Git Glossary: "dumb", "smart" l10n: zh_CN: Update Git Glossary: SHA-1 l10n: zh_CN: Add Surrounding Spaces ...
2015-09-21send-email: fix uninitialized var warning for $smtp_authLibravatar Brian Norris1-1/+1
On the latest version of git-send-email, I see this error just before running SMTP auth (I didn't provide any --smtp-auth= parameter): Use of uninitialized value $smtp_auth in pattern match (m//) at \ /home/briannorris/git/git/git-send-email.perl line 1139. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-21Documentation: explain optional arguments betterLibravatar Matthieu Moy9-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>
2015-09-21Documentation/grep: fix documentation of -OLibravatar Matthieu Moy1-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>
2015-09-21Documentation: use 'keyid' consistently, not 'key-id'Libravatar Matthieu Moy5-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>
2015-09-20l10n: de.po: better language for one stringLibravatar Phillip Sz1-1/+1
Just one string I think we could translate better. Signed-off-by: Phillip Sz <phillip.szelat@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2015-09-20l10n: de.po: translate 2 messagesLibravatar Ralf Thielow1-101/+108
Translate 2 messages came from git.pot update in e447091 (l10n: git.pot: v2.6.0 round 2 (3 improvements)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Phillip Sz <phillip.szelat@gmail.com>
2015-09-21l10n: Update and review Vietnamese translation (2440t)Libravatar Tran Ngoc Quan1-91/+90
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2015-09-21l10n: fr.po v2.6.0 round 2 (2440t)Libravatar Jean-Noel Avila1-112/+148
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
2015-09-21l10n: zh_CN: for git v2.6.0 l10n round 2Libravatar Jiang Xin1-78/+77
Update 2 translations (2440t0f0u) for git v2.6.0-rc2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2015-09-21l10n: ca.po: update translationLibravatar Alex Henrie1-1760/+2159
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
2015-09-21l10n: git.pot: v2.6.0 round 2 (3 improvements)Libravatar Jiang Xin1-76/+72
Introduce three i18n improvements from the following commits: * tag, update-ref: improve description of option "create-reflog" * pull: don't mark values for option "rebase" for translation * show-ref: place angle brackets around variables in usage string Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2015-09-21Merge branch 'master' of git://github.com/git-l10n/git-poLibravatar Jiang Xin7-9913/+12763
* 'master' of git://github.com/git-l10n/git-po: l10n: de.po: translate 123 new messages l10n: fr.po v2.6.0 round 1 (2441t) l10n: sv.po: Update Swedish translation (2441t0f0u) l10n: zh_CN: for git v2.6.0 l10n round 1 l10n: Updated Vietnamese translation (2441t) l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed) l10n: zh_CN: Update Git Glossary: "commit message" l10n: zh_CN: Update Git Glossary: pickaxe l10n: zh_CN: Update Git Glossary: fork l10n: zh_CN: Update Git Glossary: tag l10n: zh_CN: Update Git Glossary: "dumb", "smart" l10n: zh_CN: Update Git Glossary: SHA-1 l10n: zh_CN: Add Surrounding Spaces l10n: zh_CN: Add translations for Git glossary l10n: TEAMS: stash inactive zh_CN team members l10n: zh_CN: Update Translation of "tag" l10n: zh_CN: Unify Translation of "packfile" l10n: zh_CN: Update Translation: "tag object" Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2015-09-21l10n: de.po: translate 123 new messagesLibravatar Ralf Thielow1-1640/+2125
Translate 123 new messages came from git.pot update in df0617b (l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Phillip Sz <phillip.szelat@gmail.com> Acked-by: Matthias RĂ¼ster <matthias.ruester@gmail.com>
2015-09-21l10n: fr.po v2.6.0 round 1 (2441t)Libravatar Jean-Noel Avila1-1638/+2086
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
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 'et/win32-poll-timeout'Libravatar Junio C Hamano1-2/+14
* et/win32-poll-timeout: poll: honor the timeout on Win32
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