summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-01-17Merge branch 'da/difftool-dir-diff-fix' into maintLibravatar Junio C Hamano2-3/+45
"git difftool --dir-diff" had a minor regression when started from a subdirectory, which has been fixed. * da/difftool-dir-diff-fix: difftool: fix dir-diff index creation when in a subdirectory
2017-01-17Merge branch 'jb/diff-no-index-no-abbrev' into maintLibravatar Junio C Hamano8-1/+39
"git diff --no-index" did not take "--no-abbrev" option. * jb/diff-no-index-no-abbrev: diff: handle --no-abbrev in no-index case
2017-01-17Merge branch 'jk/stash-disable-renames-internally' into maintLibravatar Junio C Hamano2-1/+10
When diff.renames configuration is on (and with Git 2.9 and later, it is enabled by default, which made it worse), "git stash" misbehaved if a file is removed and another file with a very similar content is added. * jk/stash-disable-renames-internally: stash: prefer plumbing over git-diff
2017-01-17Merge branch 'jk/http-walker-limit-redirect' into maintLibravatar Junio C Hamano9-28/+165
Update the error messages from the dumb-http client when it fails to obtain loose objects; we used to give sensible error message only upon 404 but we now forbid unexpected redirects that needs to be reported with something sensible. * jk/http-walker-limit-redirect: http-walker: complain about non-404 loose object errors http: treat http-alternates like redirects http: make redirects more obvious remote-curl: rename shadowed options variable http: always update the base URL for redirects http: simplify update_url_from_redirect
2017-01-17Merge branch 'jc/renormalize-merge-kill-safer-crlf' into maintLibravatar Junio C Hamano3-6/+21
Fix a corner case in merge-recursive regression that crept in during 2.10 development cycle. * jc/renormalize-merge-kill-safer-crlf: convert: git cherry-pick -Xrenormalize did not work merge-recursive: handle NULL in add_cacheinfo() correctly cherry-pick: demonstrate a segmentation fault
2017-01-17Merge branch 'ls/p4-empty-file-on-lfs' into maintLibravatar Junio C Hamano2-12/+19
"git p4" LFS support was broken when LFS stores an empty blob. * ls/p4-empty-file-on-lfs: git-p4: fix empty file processing for large file system backend GitLFS
2017-01-17Merge branch 'da/mergetool-trust-exit-code' into maintLibravatar Junio C Hamano20-38/+75
mergetool.<tool>.trustExitCode configuration variable did not apply to built-in tools, but now it does. * da/mergetool-trust-exit-code: mergetools/vimdiff: trust Vim's exit code mergetool: honor mergetool.$tool.trustExitCode for built-in tools
2017-01-17Merge branch 'nd/worktree-list-fixup' into maintLibravatar Junio C Hamano6-30/+74
The output from "git worktree list" was made in readdir() order, and was unstable. * nd/worktree-list-fixup: worktree list: keep the list sorted worktree.c: get_worktrees() takes a new flag argument get_worktrees() must return main worktree as first item even on error worktree: reorder an if statement worktree.c: zero new 'struct worktree' on allocation
2017-01-17Merge branch 'bw/push-dry-run' into maintLibravatar Junio C Hamano4-9/+41
"git push --dry-run --recurse-submodule=on-demand" wasn't "--dry-run" in the submodules. * bw/push-dry-run: push: fix --dry-run to not push submodules push: --dry-run updates submodules when --recurse-submodules=on-demand
2017-01-17Merge branch 'hv/submodule-not-yet-pushed-fix' into maintLibravatar Junio C Hamano3-36/+121
The code in "git push" to compute if any commit being pushed in the superproject binds a commit in a submodule that hasn't been pushed out was overly inefficient, making it unusable even for a small project that does not have any submodule but have a reasonable number of refs. * hv/submodule-not-yet-pushed-fix: submodule_needs_pushing(): explain the behaviour when we cannot answer batch check whether submodule needs pushing into one call serialize collection of refs that contain submodule changes serialize collection of changed submodules
2017-01-17Merge branch 'dt/empty-submodule-in-merge' into maintLibravatar Junio C Hamano3-11/+17
An empty directory in a working tree that can simply be nuked used to interfere while merging or cherry-picking a change to create a submodule directory there, which has been fixed.. * dt/empty-submodule-in-merge: submodules: allow empty working-tree dirs in merge/cherry-pick
2017-01-17Merge branch 'jk/rev-parse-symbolic-parents-fix' into maintLibravatar Junio C Hamano2-1/+24
"git rev-parse --symbolic" failed with a more recent notation like "HEAD^-1" and "HEAD^!". * jk/rev-parse-symbolic-parents-fix: rev-parse: fix parent shorthands with --symbolic
2017-01-17Merge branch 'js/mingw-isatty' into maintLibravatar Junio C Hamano2-86/+92
Update the isatty() emulation for Windows by updating the previous hack that depended on internals of (older) MSVC runtime. * js/mingw-isatty: mingw: replace isatty() hack mingw: fix colourization on Cygwin pseudo terminals mingw: adjust is_console() to work with stdin mingw: intercept isatty() to handle /dev/null as Git expects it
2017-01-17Merge branch 'bb/unicode-9.0' into maintLibravatar Junio C Hamano6-65/+163
The character width table has been updated to match Unicode 9.0 * bb/unicode-9.0: unicode_width.h: update the width tables to Unicode 9.0 update_unicode.sh: remove the plane filter update_unicode.sh: automatically download newer definition files update_unicode.sh: pin the uniset repo to a known good commit update_unicode.sh: remove an unnecessary subshell level update_unicode.sh: move it into contrib/update-unicode
2017-01-17Merge branch 'ls/travis-update-p4-and-lfs' into maintLibravatar Junio C Hamano1-2/+2
The default Travis-CI configuration specifies newer P4 and GitLFS. * ls/travis-update-p4-and-lfs: travis-ci: update P4 to 16.2 and GitLFS to 1.5.2 in Linux build
2016-12-22mingw: replace isatty() hackLibravatar Jeff Hostetler1-107/+69
Git for Windows has carried a patch that depended on internals of MSVC runtime, but it does not work correctly with recent MSVC runtime. A replacement was written originally for compiling with VC++. The patch in this message is a backport of that replacement, and it also fixes the previous attempt to make isatty() tell that /dev/null is *not* an interactive terminal. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Tested-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-22mingw: fix colourization on Cygwin pseudo terminalsLibravatar Alan Davies1-2/+6
Git only colours the output and uses pagination if isatty() returns 1. MSYS2 and Cygwin emulate pseudo terminals via named pipes, meaning that isatty() returns 0. f7f90e0f4f (mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*), 2016-04-27) fixed this for MSYS2 terminals, but not for Cygwin. The named pipes that Cygwin and MSYS2 use are very similar. MSYS2 PTY pipes are called 'msys-*-pty*' and Cygwin uses 'cygwin-*-pty*'. This commit modifies the existing check to allow both MSYS2 and Cygwin PTY pipes to be identified as TTYs. Note that pagination is still broken when running Git for Windows from within Cygwin, as MSYS2's less.exe is spawned (and does not like to interact with Cygwin's PTY). This partially fixes https://github.com/git-for-windows/git/issues/267 Signed-off-by: Alan Davies <alan.n.davies@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-22mingw: adjust is_console() to work with stdinLibravatar Johannes Schindelin1-1/+5
When determining whether a handle corresponds to a *real* Win32 Console (as opposed to, say, a character device such as /dev/null), we use the GetConsoleOutputBufferInfo() function as a tell-tale. However, that does not work for *input* handles associated with a console. Let's just use the GetConsoleMode() function for input handles, and since it does not work on output handles fall back to the previous method for those. This patch prepares for using is_console() instead of my previous misguided attempt in cbb3f3c9b1 (mingw: intercept isatty() to handle /dev/null as Git expects it, 2016-12-11) that broke everything on Windows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14unicode_width.h: update the width tables to Unicode 9.0Libravatar Beat Bolli1-24/+107
Rerunning update-unicode.sh that we fixed in the previous commits produces these new tables. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14update_unicode.sh: remove the plane filterLibravatar Beat Bolli1-2/+1
The uniset upstream has accepted my patches that eliminate the Unicode plane offsets from the output in '--32' mode. Remove the corresponding filter in update_unicode.sh. This also fixes the issue that the plane offsets were not removed from the second uniset call. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14update_unicode.sh: automatically download newer definition filesLibravatar Beat Bolli1-6/+2
Checking just for the unicode data files' existence is not sufficient; we should also download them if a newer version exists on the Unicode consortium's servers. Option -N of wget does this nicely for us. Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-13update_unicode.sh: pin the uniset repo to a known good commitLibravatar Beat Bolli1-1/+2
The uniset upstream has added more commits that for example change the hexadecimal output in '--32' mode to decimal. Let's pin the repo to a commit that still outputs the width tables in the format we want. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-13update_unicode.sh: remove an unnecessary subshell levelLibravatar Beat Bolli1-27/+26
After the move into contrib/update-unicode, we no longer create the unicode directory to have a clean working folder. Instead, the directory of the script is used. This means that the subshell can be removed. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-13update_unicode.sh: move it into contrib/update-unicodeLibravatar Beat Bolli4-6/+26
As it's used only by a tiny minority of the Git developer population, this script does not belong into the main Git source directory. Move it into contrib/ and adjust the paths to account for the new location. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-11mingw: intercept isatty() to handle /dev/null as Git expects itLibravatar Johannes Schindelin2-0/+36
When Git's source code calls isatty(), it really asks whether the respective file descriptor is connected to an interactive terminal. Windows' _isatty() function, however, determines whether the file descriptor is associated with a character device. And NUL, Windows' equivalent of /dev/null, is a character device. Which means that for years, Git mistakenly detected an associated interactive terminal when being run through the test suite, which almost always redirects stdin, stdout and stderr to /dev/null. This bug only became obvious, and painfully so, when the new bisect--helper entered the `pu` branch and made the automatic build & test time out because t6030 was waiting for an answer. For details, see https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-08diff: handle --no-abbrev in no-index caseLibravatar Jack Bates8-1/+39
There are two different places where the --no-abbrev option is parsed, and two different places where SHA-1s are abbreviated. We normally parse --no-abbrev with setup_revisions(), but in the no-index case, "git diff" calls diff_opt_parse() directly, and diff_opt_parse() didn't handle --no-abbrev until now. (It did handle --abbrev, however.) We normally abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff: handle sha1 abbreviations outside of repository, 2016-10-20) recently introduced a special case when you run "git diff" outside of a repository. setup_revisions() does also call diff_opt_parse(), but not for --abbrev or --no-abbrev, which it handles itself. setup_revisions() sets rev_info->abbrev, and later copies that to diff_options->abbrev. It handles --no-abbrev by setting abbrev to zero. (This change doesn't touch that.) Setting abbrev to zero was broken in the outside-of-a-repository special case, which until now resulted in a truly zero-length SHA-1, rather than taking zero to mean do not abbreviate. The only way to trigger this bug, however, was by running "git diff --raw" without either the --abbrev or --no-abbrev options, because 1) without --raw it doesn't respect abbrev (which is bizarre, but has been that way forever), 2) we silently clamp --abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until now. The outside-of-a-repository case is one of three no-index cases. The other two are when one of the files you're comparing is outside of the repository you're in, and the --no-index option. Signed-off-by: Jack Bates <jack@nottheoilrig.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-08difftool: fix dir-diff index creation when in a subdirectoryLibravatar David Aguilar2-3/+45
9ec26e7977 (difftool: fix argument handling in subdirs, 2016-07-18) corrected how path arguments are handled in a subdirectory, but it introduced a regression in how entries outside of the subdirectory are handled by dir-diff. When preparing the right-side of the diff we only include the changed paths in the temporary area. The left side of the diff is constructed from a temporary index that is built from the same set of changed files, but it was being constructed from within the subdirectory. This is a problem because the indexed paths are toplevel-relative, and thus they were not getting added to the index. Teach difftool to chdir to the toplevel of the repository before preparing its temporary indexes. This ensures that all of the toplevel-relative paths are valid. Add test cases to more thoroughly exercise this scenario. Reported-by: Frank Becker <fb@mooflu.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06stash: prefer plumbing over git-diffLibravatar Jeff King2-1/+10
When creating a stash, we need to look at the diff between the working tree and HEAD, and do so using the git-diff porcelain. Because git-diff enables porcelain config like renames by default, this causes at least one problem. The --name-only format will not mention the source side of a rename, meaning we will fail to stash a deletion that is part of a rename. We could fix that case by passing --no-renames, but this is a symptom of a larger problem. We should be using the diff-index plumbing here, which does not have renames enabled by default, and also does not respect any potentially confusing config options. Reported-by: Matthew Patey <matthew.patey2167@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06http-walker: complain about non-404 loose object errorsLibravatar Jeff King2-3/+6
Since commit 17966c0a6 (http: avoid disconnecting on 404s for loose objects, 2016-07-11), we turn off curl's FAILONERROR option and instead manually deal with failing HTTP codes. However, the logic to do so only recognizes HTTP 404 as a failure. This is probably the most common result, but if we were to get another code, the curl result remains CURLE_OK, and we treat it as success. We still end up detecting the failure when we try to zlib-inflate the object (which will fail), but instead of reporting the HTTP error, we just claim that the object is corrupt. Instead, let's catch anything in the 300's or above as an error (300's are redirects which are not an error at the HTTP level, but are an indication that we've explicitly disabled redirects, so we should treat them as such; we certainly don't have the resulting object content). Note that we also fill in req->errorstr, which we didn't do before. Without FAILONERROR, curl will not have filled this in, and it will remain a blank string. This never mattered for the 404 case, because in the logic below we hit the "missing_target()" branch and print nothing. But for other errors, we'd want to say _something_, if only to fill in the blank slot in the error message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06Merge branch 'ew/http-walker' into jk/http-walker-limit-redirectLibravatar Junio C Hamano3-31/+206
* ew/http-walker: list: avoid incompatibility with *BSD sys/queue.h http-walker: reduce O(n) ops with doubly-linked list http: avoid disconnecting on 404s for loose objects http-walker: remove unused parameter from fetch_object
2016-12-06http: treat http-alternates like redirectsLibravatar Jeff King3-3/+44
The previous commit made HTTP redirects more obvious and tightened up the default behavior. However, there's another way for a server to ask a git client to fetch arbitrary content: by having an http-alternates file (or a regular alternates file, which is used as a backup). Similar to the HTTP redirect case, a malicious server can claim to have refs pointing at object X, return a 404 when the client asks for X, but point to some other URL via http-alternates, which the client will transparently fetch. The end result is that it looks from the user's perspective like the objects came from the malicious server, as the other URL is not mentioned at all. Worse, because we feed the new URL to curl ourselves, the usual protocol restrictions do not kick in (neither curl's default of disallowing file://, nor the protocol whitelisting in f4113cac0 (http: limit redirection to protocol-whitelist, 2015-09-22). Let's apply the same rules here as we do for HTTP redirects. Namely: - unless http.followRedirects is set to "always", we will not follow remote redirects from http-alternates (or alternates) at all - set CURLOPT_PROTOCOLS alongside CURLOPT_REDIR_PROTOCOLS restrict ourselves to a known-safe set and respect any user-provided whitelist. - mention alternate object stores on stderr so that the user is aware another source of objects may be involved The first item may prove to be too restrictive. The most common use of alternates is to point to another path on the same server. While it's possible for a single-server redirect to be an attack, it takes a fairly obscure setup (victim and evil repository on the same host, host speaks dumb http, and evil repository has access to edit its own http-alternates file). So we could make the checks more specific, and only cover cross-server redirects. But that means parsing the URLs ourselves, rather than letting curl handle them. This patch goes for the simpler approach. Given that they are only used with dumb http, http-alternates are probably pretty rare. And there's an escape hatch: the user can allow redirects on a specific server by setting http.<url>.followRedirects to "always". Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06http: make redirects more obviousLibravatar Jeff King6-3/+81
We instruct curl to always follow HTTP redirects. This is convenient, but it creates opportunities for malicious servers to create confusing situations. For instance, imagine Alice is a git user with access to a private repository on Bob's server. Mallory runs her own server and wants to access objects from Bob's repository. Mallory may try a few tricks that involve asking Alice to clone from her, build on top, and then push the result: 1. Mallory may simply redirect all fetch requests to Bob's server. Git will transparently follow those redirects and fetch Bob's history, which Alice may believe she got from Mallory. The subsequent push seems like it is just feeding Mallory back her own objects, but is actually leaking Bob's objects. There is nothing in git's output to indicate that Bob's repository was involved at all. The downside (for Mallory) of this attack is that Alice will have received Bob's entire repository, and is likely to notice that when building on top of it. 2. If Mallory happens to know the sha1 of some object X in Bob's repository, she can instead build her own history that references that object. She then runs a dumb http server, and Alice's client will fetch each object individually. When it asks for X, Mallory redirects her to Bob's server. The end result is that Alice obtains objects from Bob, but they may be buried deep in history. Alice is less likely to notice. Both of these attacks are fairly hard to pull off. There's a social component in getting Mallory to convince Alice to work with her. Alice may be prompted for credentials in accessing Bob's repository (but not always, if she is using a credential helper that caches). Attack (1) requires a certain amount of obliviousness on Alice's part while making a new commit. Attack (2) requires that Mallory knows a sha1 in Bob's repository, that Bob's server supports dumb http, and that the object in question is loose on Bob's server. But we can probably make things a bit more obvious without any loss of functionality. This patch does two things to that end. First, when we encounter a whole-repo redirect during the initial ref discovery, we now inform the user on stderr, making attack (1) much more obvious. Second, the decision to follow redirects is now configurable. The truly paranoid can set the new http.followRedirects to false to avoid any redirection entirely. But for a more practical default, we will disallow redirects only after the initial ref discovery. This is enough to thwart attacks similar to (2), while still allowing the common use of redirects at the repository level. Since c93c92f30 (http: update base URLs when we see redirects, 2013-09-28) we re-root all further requests from the redirect destination, which should generally mean that no further redirection is necessary. As an escape hatch, in case there really is a server that needs to redirect individual requests, the user can set http.followRedirects to "true" (and this can be done on a per-server basis via http.*.followRedirects config). Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06remote-curl: rename shadowed options variableLibravatar Jeff King1-9/+9
The discover_refs() function has a local "options" variable to hold the http_get_options we pass to http_get_strbuf(). But this shadows the global "struct options" that holds our program-level options, which cannot be accessed from this function. Let's give the local one a more descriptive name so we can tell the two apart. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06http: always update the base URL for redirectsLibravatar Jeff King4-4/+21
If a malicious server redirects the initial ref advertisement, it may be able to leak sha1s from other, unrelated servers that the client has access to. For example, imagine that Alice is a git user, she has access to a private repository on a server hosted by Bob, and Mallory runs a malicious server and wants to find out about Bob's private repository. Mallory asks Alice to clone an unrelated repository from her over HTTP. When Alice's client contacts Mallory's server for the initial ref advertisement, the server issues an HTTP redirect for Bob's server. Alice contacts Bob's server and gets the ref advertisement for the private repository. If there is anything to fetch, she then follows up by asking the server for one or more sha1 objects. But who is the server? If it is still Mallory's server, then Alice will leak the existence of those sha1s to her. Since commit c93c92f30 (http: update base URLs when we see redirects, 2013-09-28), the client usually rewrites the base URL such that all further requests will go to Bob's server. But this is done by textually matching the URL. If we were originally looking for "http://mallory/repo.git/info/refs", and we got pointed at "http://bob/other.git/info/refs", then we know that the right root is "http://bob/other.git". If the redirect appears to change more than just the root, we punt and continue to use the original server. E.g., imagine the redirect adds a URL component that Bob's server will ignore, like "http://bob/other.git/info/refs?dummy=1". We can solve this by aborting in this case rather than silently continuing to use Mallory's server. In addition to protecting from sha1 leakage, it's arguably safer and more sane to refuse a confusing redirect like that in general. For example, part of the motivation in c93c92f30 is avoiding accidentally sending credentials over clear http, just to get a response that says "try again over https". So even in a non-malicious case, we'd prefer to err on the side of caution. The downside is that it's possible this will break a legitimate but complicated server-side redirection scheme. The setup given in the newly added test does work, but it's convoluted enough that we don't need to care about it. A more plausible case would be a server which redirects a request for "info/refs?service=git-upload-pack" to just "info/refs" (because it does not do smart HTTP, and for some reason really dislikes query parameters). Right now we would transparently downgrade to dumb-http, but with this patch, we'd complain (and the user would have to set GIT_SMART_HTTP=0 to fetch). Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06http: simplify update_url_from_redirectLibravatar Jeff King1-6/+4
This function looks for a common tail between what we asked for and where we were redirected to, but it open-codes the comparison. We can avoid some confusing subtractions by using strip_suffix_mem(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05git-p4: fix empty file processing for large file system backend GitLFSLibravatar Lars Schneider2-12/+19
If git-p4 tried to store an empty file in GitLFS then it crashed while parsing the pointer file: oid = re.search(r'^oid \w+:(\w+)', pointerFile, re.MULTILINE).group(1) AttributeError: 'NoneType' object has no attribute 'group' This happens because GitLFS does not create a pointer file for an empty file. Teach git-p4 this behavior to fix the problem and add a test case. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05travis-ci: update P4 to 16.2 and GitLFS to 1.5.2 in Linux buildLibravatar Lars Schneider1-2/+2
Update Travis-CI dependencies to the latest available versions in Linux build. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05Sync with maint-2.10Libravatar Junio C Hamano1-0/+48
* maint-2.10: preparing for 2.10.3
2016-12-05preparing for 2.10.3Libravatar Junio C Hamano2-1/+49
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05Merge branch 'jk/common-main' into maint-2.10Libravatar Junio C Hamano5-11/+12
* jk/common-main: common-main: stop munging argv[0] path git-compat-util: move content inside ifdef/endif guards
2016-12-01convert: git cherry-pick -Xrenormalize did not workLibravatar Torsten Bögershausen1-6/+7
Working with a repo that used to be all CRLF. At some point it was changed to all LF, with `text=auto` in .gitattributes. Trying to cherry-pick a commit from before the switchover fails: $ git cherry-pick -Xrenormalize <commit> fatal: CRLF would be replaced by LF in [path] Commit 65237284 "unify the "auto" handling of CRLF" introduced a regression: Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX, SAFE_CRLF_RENORMALIZE was feed into check_safe_crlf(). This is wrong because here everything else than SAFE_CRLF_WARN is treated as SAFE_CRLF_FAIL. Call check_safe_crlf() only if checksafe is SAFE_CRLF_WARN or SAFE_CRLF_FAIL. Reported-by: Eevee (Lexy Munroe) <eevee@veekun.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-01Merge branch 'tb/t0027-raciness-fix' into jc/renormalize-merge-kill-safer-crlfLibravatar Junio C Hamano2-43/+60
* tb/t0027-raciness-fix: convert: Correct NNO tests and missing `LF will be replaced by CRLF`
2016-11-29Merge branch 'tk/diffcore-delta-remove-unused' into maintLibravatar Junio C Hamano5-8/+1
Code cleanup. * tk/diffcore-delta-remove-unused: diffcore-delta: remove unused parameter to diffcore_count_changes()
2016-11-29Merge branch 'jk/create-branch-remove-unused-param' into maintLibravatar Junio C Hamano4-13/+18
Code clean-up. * jk/create-branch-remove-unused-param: create_branch: drop unused "head" parameter
2016-11-29Merge branch 'nd/worktree-lock' into maintLibravatar Junio C Hamano1-1/+1
Typofix. * nd/worktree-lock: git-worktree.txt: fix typo "to"/"two", and add comma
2016-11-29Merge branch 'ps/common-info-doc' into maintLibravatar Junio C Hamano1-1/+1
Doc fix. * ps/common-info-doc: doc: fix location of 'info/' with $GIT_COMMON_DIR
2016-11-29Merge branch 'rs/cocci' into maintLibravatar Junio C Hamano1-0/+15
Improve the rule to convert "unsigned char [20]" into "struct object_id *" in contrib/coccinelle/ * rs/cocci: cocci: avoid self-references in object_id transformations
2016-11-29Merge branch 'nd/test-helpers' into maintLibravatar Junio C Hamano2-3/+18
Update to the test framework made in 2.9 timeframe broke running the tests under valgrind, which has been fixed. * nd/test-helpers: valgrind: support test helpers
2016-11-29Merge branch 'sc/fmt-merge-msg-doc-markup-fix' into maintLibravatar Junio C Hamano1-2/+2
Documentation fix. * sc/fmt-merge-msg-doc-markup-fix: Documentation/fmt-merge-msg: fix markup in example
2016-11-29Merge branch 'rs/commit-pptr-simplify' into maintLibravatar Junio C Hamano1-8/+6
Code simplification. * rs/commit-pptr-simplify: commit: simplify building parents list