summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-21configure.ac: detect ssl need with libcurlLibravatar Remi Pommarel1-0/+10
When libcurl has been statically compiled with openssl support they both need to be linked in everytime libcurl is used. During configuration this can be detected by looking for Curl_ssl_init function symbol in libcurl, which will only be present if libcurl has been compiled statically built with openssl. configure.ac checks for Curl_ssl_init function in libcurl and if such function exists; it sets NEEDS_SSL_WITH_CURL that is used by the Makefile to include -lssl alongside with -lcurl. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-21Makefile: make curl-config path configurableLibravatar Remi Pommarel2-2/+19
There are situations, e.g. during cross compilation, where curl-config program is not present in the PATH. Make the makefile use a configurable curl-config program passed through CURL_CONFIG variable which can be set through config.mak. Also make this variable tunable through use of autoconf/configure. Configure will set CURL_CONFIG variable in config.mak.autogen to whatever value has been passed to ac_cv_prog_CURL_CONFIG. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-21Makefile: link libcurl before zlibLibravatar Remi Pommarel1-4/+5
For static linking especially library order while linking is important. For example, libcurl wants symbols from zlib when building http-push, http-fetch and remote-curl. So for these programs libcurl has to be linked before zlib. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Git 2.5.3Libravatar Junio C Hamano4-3/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Merge branch 'dt/untracked-subdir' into maintLibravatar Junio C Hamano2-32/+282
The experimental untracked-cache feature were buggy when paths with a few levels of subdirectories are involved. * dt/untracked-subdir: untracked cache: fix entry invalidation untracked-cache: fix subdirectory handling t7063: use --force-untracked-cache to speed up a bit untracked-cache: support sparse checkout
2015-09-17Merge branch 'br/svn-doc-include-paths-config' into maintLibravatar Junio C Hamano1-0/+3
* br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths"
2015-09-17Merge branch 'ah/submodule-typofix-in-error' into maintLibravatar Junio C Hamano1-1/+1
Error string fix. * ah/submodule-typofix-in-error: git-submodule: remove extraneous space from error message
2015-09-17Merge branch 'js/maint-am-skip-performance-regression' into maintLibravatar Junio C Hamano1-1/+1
* js/maint-am-skip-performance-regression: am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
2015-09-09am --skip/--abort: merge HEAD/ORIG_HEAD tree into indexLibravatar Johannes Schindelin1-1/+1
f8da6801 (am --skip: support skipping while on unborn branch, 2015-06-06) introduced a performance regression to "git am --skip", where it used "read-tree" to reconstruct the index from scratch without reusing the cached stat information. This is a backport of the corresponding patch to the builtin am in 2.6: 3ecc704 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index, 2015-08-19). Reportedly, it can make a huge difference on Windows, in one case a `git rebase --skip` took 1m40s without, and 5s with, this patch. cf. https://github.com/git-for-windows/git/issues/365 Reported-and-suggested-by: Kim Gybels <kgybels@infogroep.be> Acked-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Git 2.5.2Libravatar Junio C Hamano4-3/+67
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.4.9Libravatar Junio C Hamano8-27/+60
2015-09-04Git 2.4.9Libravatar Junio C Hamano4-3/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.3.9Libravatar Junio C Hamano7-26/+49
2015-09-04Git 2.3.9Libravatar Junio C Hamano4-3/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.2.3Libravatar Junio C Hamano6-25/+38
2015-09-04Git 2.2.3Libravatar Junio C Hamano4-3/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Merge branch 'jk/long-paths' into maint-2.2Libravatar Junio C Hamano4-24/+27
2015-09-04show-branch: use a strbuf for reflog descriptionsLibravatar Jeff King1-2/+4
When we show "branch@{0}", we format into a fixed-size buffer using sprintf. This can overflow if you have long branch names. We can fix it by using a temporary strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04read_info_alternates: handle paths larger than PATH_MAXLibravatar Jeff King1-6/+3
This function assumes that the relative_base path passed into it is no larger than PATH_MAX, and writes into a fixed-size buffer. However, this path may not have actually come from the filesystem; for example, add_submodule_odb generates a path using a strbuf and passes it in. This is hard to trigger in practice, though, because the long submodule directory would have to exist on disk before we would try to open its info/alternates file. We can easily avoid the bug, though, by simply creating the filename on the heap. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04notes: use a strbuf in add_non_noteLibravatar Jeff King1-9/+10
When we are loading a notes tree into our internal hash table, we also collect any files that are clearly non-notes. We format the name of the file into a PATH_MAX buffer, but unlike true notes (which cannot be larger than a fanned-out sha1 hash), these tree entries can be arbitrarily long, overflowing our buffer. We can fix this by switching to a strbuf. It doesn't even cost us an extra allocation, as we can simply hand ownership of the buffer over to the non-note struct. This is of moderate security interest, as you might fetch notes trees from an untrusted remote. However, we do not do so by default, so you would have to manually fetch into the notes namespace. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04verify_absent: allow filenames longer than PATH_MAXLibravatar Jeff King1-7/+10
When unpack-trees wants to know whether a path will overwrite anything in the working tree, we use lstat() to see if there is anything there. But if we are going to write "foo/bar", we can't just lstat("foo/bar"); we need to look for leading prefixes (e.g., "foo"). So we use the lstat cache to find the length of the leading prefix, and copy the filename up to that length into a temporary buffer (since the original name is const, we cannot just stick a NUL in it). The copy we make goes into a PATH_MAX-sized buffer, which will overflow if the prefix is longer than PATH_MAX. How this happens is a little tricky, since in theory PATH_MAX is the biggest path we will have read from the filesystem. But this can happen if: - the compiled-in PATH_MAX does not accurately reflect what the filesystem is capable of - the leading prefix is not _quite_ what is on disk; it contains the next element from the name we are checking. So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb" exists, the prefix of interest is "aaa/bbb/ccc". If "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow it. So this can be triggered, but it's hard to do. In particular, you cannot just "git clone" a bogus repo. The verify_absent checks happen before unpack-trees writes anything to the filesystem, so there are never any leading prefixes during the initial checkout, and the bug doesn't trigger. And by definition, these files are larger than PATH_MAX, so writing them will fail, and clone will complain (though it may write a partial path, which will cause a subsequent "git checkout" to hit the bug). We can fix it by creating the temporary path on the heap. The extra malloc overhead is not important, as we are already making at least one stat() call (and probably more for the prefix discovery). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03Merge branch 'ee/clean-test-fixes' into maintLibravatar Junio C Hamano1-12/+4
* ee/clean-test-fixes: t7300: fix broken && chains
2015-09-03Merge branch 'jk/log-missing-default-HEAD' into maintLibravatar Junio C Hamano2-1/+30
"git init empty && git -C empty log" said "bad default revision 'HEAD'", which was found to be a bit confusing to new users. * jk/log-missing-default-HEAD: log: diagnose empty HEAD more clearly
2015-09-03Merge branch 'cc/trailers-corner-case-fix' into maintLibravatar Junio C Hamano2-3/+39
The "interpret-trailers" helper mistook a multi-paragraph title of a commit log message with a colon in it as the end of the trailer block. * cc/trailers-corner-case-fix: trailer: support multiline title trailer: retitle a test and correct an in-comment message trailer: ignore first line of message
2015-09-03Merge branch ↵Libravatar Junio C Hamano3-5/+15
'dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update' into maint When re-priming the cache-tree opportunistically while committing the in-core index as-is, we mistakenly invalidated the in-core index too aggressively, causing the experimental split-index code to unnecessarily rewrite the on-disk index file(s). * dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update: commit: don't rewrite shared index unnecessarily
2015-09-03Merge branch 'rs/archive-zip-many' into maintLibravatar Junio C Hamano2-5/+134
"git archive" did not use zip64 extension when creating an archive with more than 64k entries, which nobody should need, right ;-)? * rs/archive-zip-many: archive-zip: support more than 65535 entries archive-zip: use a local variable to store the creator version t5004: test ZIP archives with many entries
2015-09-03Merge branch 'jc/calloc-pathspec' into maintLibravatar Junio C Hamano2-2/+2
Minor code cleanup. * jc/calloc-pathspec: ps_matched: xcalloc() takes nmemb and then element size
2015-09-03Merge branch 'ss/fix-config-fd-leak' into maintLibravatar Junio C Hamano1-1/+4
* ss/fix-config-fd-leak: config: close config file handle in case of error
2015-09-03Merge branch 'sg/wt-status-header-inclusion' into maintLibravatar Junio C Hamano2-1/+1
* sg/wt-status-header-inclusion: wt-status: move #include "pathspec.h" to the header
2015-09-03Merge branch 'po/po-readme' into maintLibravatar Junio C Hamano1-0/+19
Doc updates for i18n. * po/po-readme: po/README: Update directions for l10n contributors
2015-09-03Merge branch 'sg/t3020-typofix' into maintLibravatar Junio C Hamano1-1/+1
* sg/t3020-typofix: t3020: fix typo in test description
2015-09-03Merge branch 'as/docfix-reflog-expire-unreachable' into maintLibravatar Junio C Hamano1-1/+1
Docfix. * as/docfix-reflog-expire-unreachable: Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable
2015-09-03Merge branch 'nd/fixup-linked-gitdir' into maintLibravatar Junio C Hamano1-2/+2
The code in "multiple-worktree" support that attempted to recover from an inconsistent state updated an incorrect file. * nd/fixup-linked-gitdir: setup: update the right file in multiple checkouts
2015-09-03Merge branch 'jk/rev-list-has-no-notes' into maintLibravatar Junio C Hamano4-0/+9
"git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes
2015-09-03Merge branch 'jk/fix-alias-pager-config-key-warnings' into maintLibravatar Junio C Hamano5-12/+43
Because the configuration system does not allow "alias.0foo" and "pager.0foo" as the configuration key, the user cannot use '0foo' as a custom command name anyway, but "git 0foo" tried to look these keys up and emitted useless warnings before saying '0foo is not a git command'. These warning messages have been squelched. * jk/fix-alias-pager-config-key-warnings: config: silence warnings for command names with invalid keys
2015-09-03Merge branch 'nd/dwim-wildcards-as-pathspecs' into maintLibravatar Junio C Hamano1-1/+1
Test updates for Windows. * nd/dwim-wildcards-as-pathspecs: t2019: skip test requiring '*' in a file name non Windows
2015-09-03Merge branch 'sg/help-group' into maintLibravatar Junio C Hamano3-52/+52
We rewrote one of the build scripts in Perl but this reimplements in Bourne shell. * sg/help-group: generate-cmdlist: re-implement as shell script
2015-09-03Merge branch 'ps/t1509-chroot-test-fixup' into maintLibravatar Junio C Hamano1-4/+4
t1509 test that requires a dedicated VM environment had some bitrot, which has been corrected. * ps/t1509-chroot-test-fixup: tests: fix cleanup after tests in t1509-root-worktree tests: fix broken && chains in t1509-root-worktree
2015-09-03Merge branch 'jh/strbuf-read-use-read-in-full' into maintLibravatar Junio C Hamano1-5/+5
strbuf_read() used to have one extra iteration (and an unnecessary strbuf_grow() of 8kB), which was eliminated. * jh/strbuf-read-use-read-in-full: strbuf_read(): skip unnecessary strbuf_grow() at eof
2015-09-03Merge branch 'jk/long-error-messages' into maintLibravatar Junio C Hamano3-29/+21
The codepath to produce error messages had a hard-coded limit to the size of the message, primarily to avoid memory allocation while calling die(). * jk/long-error-messages: vreportf: avoid intermediate buffer vreportf: report to arbitrary filehandles
2015-09-03Merge branch 'cb/open-noatime-clear-errno' into maintLibravatar Junio C Hamano1-1/+4
When trying to see that an object does not exist, a state errno leaked from our "first try to open a packfile with O_NOATIME and then if it fails retry without it" logic on a system that refuses O_NOATIME. This confused us and caused us to die, saying that the packfile is unreadable, when we should have just reported that the object does not exist in that packfile to the caller. * cb/open-noatime-clear-errno: git_open_noatime: return with errno=0 on success
2015-09-03Merge branch 'mh/get-remote-group-fix' into maintLibravatar Junio C Hamano1-8/+6
An off-by-one error made "git remote" to mishandle a remote with a single letter nickname. * mh/get-remote-group-fix: get_remote_group(): use skip_prefix() get_remote_group(): eliminate superfluous call to strcspn() get_remote_group(): rename local variable "space" to "wordlen" get_remote_group(): handle remotes with single-character names
2015-08-31trailer: support multiline titleLibravatar Christian Couder2-4/+25
We currently ignore the first line passed to `git interpret-trailers`, when looking for the beginning of the trailers. Unfortunately this does not work well when a commit is created with a line break in the title, using for example the following command: git commit -m 'place of code: change we made' That's why instead of ignoring only the first line, it is better to ignore the first paragraph. Signed-off-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31t7300: fix broken && chainsLibravatar Erik Elfström1-12/+4
While we are here, remove some boilerplate by using test_commit. Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31log: diagnose empty HEAD more clearlyLibravatar Jeff King2-1/+30
If you init or clone an empty repository, the initial message from running "git log" is not very friendly: $ git init Initialized empty Git repository in /home/peff/foo/.git/ $ git log fatal: bad default revision 'HEAD' Let's detect this situation and write a more friendly message: $ git log fatal: your current branch 'master' does not have any commits yet We also detect the case that 'HEAD' points to a broken ref; this should be even less common, but is easy to see. Note that we do not diagnose all possible cases. We rely on resolve_ref, which means we do not get information about complex cases. E.g., "--default master" would use dwim_ref to find "refs/heads/master", but we notice only that "master" does not exist. Similarly, a complex sha1 expression like "--default HEAD^2" will not resolve as a ref. But that's OK. We fall back to a generic error message in those cases, and they are unlikely to be used anyway. Catching an empty or broken "HEAD" improves the common case, and the other cases are not regressed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31commit: don't rewrite shared index unnecessarilyLibravatar David Turner3-5/+15
Remove a cache invalidation which would cause the shared index to be rewritten on as-is commits. When the cache-tree has changed, we need to update it. But we don't necessarily need to update the shared index. So setting active_cache_changed to SOMETHING_CHANGED is unnecessary. Instead, we let update_main_cache_tree just update the CACHE_TREE_CHANGED bit. In order to test this, make test-dump-split-index not segfault on missing replace_bitmap/delete_bitmap. This new codepath is not called now that the test passes, but is necessary to avoid a segfault when the new test is run with the old builtin/commit.c code. Signed-off-by: David Turner <dturner@twopensource.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28git-submodule: remove extraneous space from error messageLibravatar Alex Henrie1-1/+1
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28Git 2.5.1Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28Mingw: verify both ends of the pipe () callLibravatar Jose F. Morales1-1/+1
The code to open and test the second end of the pipe clearly imitates the code for the first end. A little too closely, though... Let's fix the obvious copy-edit bug. Signed-off-by: Jose F. Morales <jfmcjf@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28archive-zip: support more than 65535 entriesLibravatar René Scharfe2-4/+91
Support more than 65535 entries cleanly by writing a "zip64 end of central directory record" (with a 64-bit field for the number of entries) before the usual "end of central directory record" (which contains only a 16-bit field). InfoZIP's zip does the same. Archives with 65535 or less entries are not affected. Programs that extract all files like InfoZIP's zip and 7-Zip ignored the field and could extract all files already. Software that relies on the ZIP file directory to show a list of contained files quickly to simulate to normal directory like Windows' built-in ZIP functionality only saw a subset of the included files. Windows supports ZIP64 since Vista according to https://en.wikipedia.org/wiki/Zip_%28file_format%29#ZIP64. Suggested-by: Johannes Schauer <josch@debian.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>