- 08 10月, 2015 1 次提交
-
-
由 Christian Couder 提交于
Since 77d604c3 (Enhanced sq_quote(), 10 Oct 2005), the comment at the beginning of quote.c is broken. Let's fix it. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 9月, 2015 14 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 9月, 2015 3 次提交
-
-
由 Blake Burkhart 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Blake Burkhart 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NBlake Burkhart <bburky@bburky.com> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 9月, 2015 2 次提交
-
-
由 Jeff King 提交于
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: NBlake Burkhart <bburky@bburky.com> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 9月, 2015 5 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* rj/mailmap-ramsay: mailmap: update my entry with new email address
-
由 Junio C Hamano 提交于
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
-
git://github.com/git-l10n/git-po由 Junio C Hamano 提交于
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 ...
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 9月, 2015 10 次提交
-
-
由 Phillip Sz 提交于
Just one string I think we could translate better. Signed-off-by: NPhillip Sz <phillip.szelat@gmail.com> Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>
-
由 Ralf Thielow 提交于
Translate 2 messages came from git.pot update in e447091 (l10n: git.pot: v2.6.0 round 2 (3 improvements)). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Acked-by: NPhillip Sz <phillip.szelat@gmail.com>
-
由 Tran Ngoc Quan 提交于
Signed-off-by: NTran Ngoc Quan <vnwildman@gmail.com>
-
由 Jean-Noel Avila 提交于
Signed-off-by: NJean-Noel Avila <jn.avila@free.fr>
-
由 Jiang Xin 提交于
Update 2 translations (2440t0f0u) for git v2.6.0-rc2. Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
-
由 Alex Henrie 提交于
Signed-off-by: NAlex Henrie <alexhenrie24@gmail.com>
-
由 Jiang Xin 提交于
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: NJiang Xin <worldhello.net@gmail.com>
-
git://github.com/git-l10n/git-po由 Jiang Xin 提交于
* '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: NJiang Xin <worldhello.net@gmail.com>
-
由 Ralf Thielow 提交于
Translate 123 new messages came from git.pot update in df0617bf (l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Acked-by: NPhillip Sz <phillip.szelat@gmail.com> Acked-by: NMatthias Rüster <matthias.ruester@gmail.com>
-
由 Jean-Noel Avila 提交于
Signed-off-by: NJean-Noel Avila <jn.avila@free.fr>
-
- 18 9月, 2015 5 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: Git 2.5.3
-
由 Junio C Hamano 提交于
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
-
由 Junio C Hamano 提交于
* et/win32-poll-timeout: poll: honor the timeout on Win32
-
由 Junio C Hamano 提交于
* as/config-doc-markup-fix: Documentation/config: fix formatting for branch.*.rebase and pull.rebase
-