summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-12-11send-email: enable SSL level 1 debug outputLibravatar John Keeping1-0/+7
If a server's certificate isn't accepted by send-email, the output is: Unable to initialize SMTP properly. Check config and use --smtp-debug. but adding --smtp-debug=1 just produces the same output since we don't get as far as talking SMTP. Turning on SSL debug at level 1 gives: DEBUG: .../IO/Socket/SSL.pm:1796: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:673: fatal SSL error: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:1780: IO::Socket::IP configuration failed IO::Socket::SSL defines level 1 debug as "print out errors from IO::Socket::SSL and ciphers from Net::SSLeay". In fact, it aliases Net::SSLeay::trace which is defined to guarantee silence at level 0 and only emit error messages at level 1, so let's enable it by default. The modification of warnings is needed to avoid a warning about: Name "IO::Socket::SSL::DEBUG" used only once: possible typo Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-24Documentation/git-update-index: add missing opts to synopsysLibravatar Christian Couder1-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>
2015-11-05Git 2.6.3Libravatar Junio C Hamano4-3/+115
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-05Merge branch 'rs/daemon-plug-child-leak' into maintLibravatar Junio C Hamano4-6/+18
"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()
2015-11-05Merge branch 'rs/wt-status-detached-branch-fix' into maintLibravatar Junio C Hamano2-35/+43
"git status --branch --short" accessed beyond the constant string "HEAD", which has been corrected. * rs/wt-status-detached-branch-fix: wt-status: use skip_prefix() to get rid of magic string length constants wt-status: don't skip a magical number of characters blindly wt-status: avoid building bogus branch name with detached HEAD wt-status: exit early using goto in wt_shortstatus_print_tracking() t7060: add test for status --branch on a detached HEAD
2015-11-05Merge branch 'jk/initialization-fix-to-add-submodule-odb' into maintLibravatar Junio C Hamano1-1/+1
We peek objects from submodule's object store by linking it to the list of alternate object databases, but the code to do so forgot to correctly initialize the list. * jk/initialization-fix-to-add-submodule-odb: add_submodule_odb: initialize alt_odb list earlier
2015-11-05Merge branch 'js/misc-fixes' into maintLibravatar Junio C Hamano5-6/+12
Various compilation fixes and squelching of warnings. * js/misc-fixes: Correct fscanf formatting string for I64u values Silence GCC's "cast of pointer to integer of a different size" warning Squelch warning about an integer overflow
2015-11-05Merge branch 'jc/add-u-A-default-to-top' into maintLibravatar Junio C Hamano3-7/+4
"git --literal-pathspecs add -u/-A" without any command line argument misbehaved ever since Git 2.0. * jc/add-u-A-default-to-top: add: simplify -u/-A without pathspec
2015-11-05Merge branch 'jk/delete-modechange-conflict' into maintLibravatar Junio C Hamano5-89/+144
Merging a branch that removes a path and another that changes the mode bits on the same path should have conflicted at the path, but it didn't and silently favoured the removal. * jk/delete-modechange-conflict: merge: detect delete/modechange conflict t6031: generalize for recursive and resolve strategies t6031: move triple-rename test to t3030
2015-11-05Merge branch 'js/imap-send-curl-compilation-fix' into maintLibravatar Junio C Hamano1-0/+4
"git imap-send" did not compile well with older version of cURL library. * js/imap-send-curl-compilation-fix: imap-send: only use CURLOPT_LOGIN_OPTIONS if it is actually available
2015-11-05Merge branch 'rp/link-curl-before-ssl' into maintLibravatar Junio C Hamano2-6/+34
The linkage order of libraries was wrong in places around libcurl. * rp/link-curl-before-ssl: configure.ac: detect ssl need with libcurl Makefile: make curl-config path configurable Makefile: link libcurl before zlib
2015-11-05Merge branch 'nd/clone-linked-checkout' into maintLibravatar Junio C Hamano4-8/+66
It was not possible to use a repository-lookalike created by "git worktree add" as a local source of "git clone". * nd/clone-linked-checkout: clone: better error when --reference is a linked checkout clone: allow --local from a linked checkout enter_repo: allow .git files in strict mode enter_repo: avoid duplicating logic, use is_git_directory() instead t0002: add test for enter_repo(), non-strict mode path.c: delete an extra space
2015-11-05Merge branch 'sa/send-email-smtp-batch-data-limit' into maintLibravatar Junio C Hamano1-1/+5
When "git send-email" wanted to talk over Net::SMTP::SSL, Net::Cmd::datasend() did not like to be fed too many bytes at the same time and failed to send messages. Send the payload one line at a time to work around the problem. * sa/send-email-smtp-batch-data-limit: git-send-email.perl: Fixed sending of many/huge changes/patches
2015-11-04Merge branch 'xf/user-manual-ff' into maintLibravatar Junio C Hamano1-5/+5
* xf/user-manual-ff: user-manual: fix the description of fast-forward
2015-11-04Merge branch 'xf/user-manual-markup' into maintLibravatar Junio C Hamano11-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
2015-11-04Merge branch 'jc/everyday-markup' into maintLibravatar Junio C Hamano1-1/+1
AsciiDoc markup fixes. * jc/everyday-markup: Documentation/everyday: match undefline with the text
2015-11-04Merge branch 'jc/em-dash-in-doc' into maintLibravatar Junio C Hamano6-6/+6
AsciiDoc markup fixes. * jc/em-dash-in-doc: Documentation: AsciiDoc spells em-dash as double-dashes, not triple
2015-11-04Merge branch 'es/worktree-add' into maintLibravatar Junio C Hamano1-1/+1
* es/worktree-add: worktree: usage: denote <branch> as optional with 'add'
2015-11-03Merge branch 'mk/blame-error-message' into maintLibravatar Junio C Hamano1-1/+1
The error message from "git blame --contents --reverse" incorrectly talked about "--contents --children". * mk/blame-error-message: blame: fix option name in error message
2015-11-03Merge branch 'jk/merge-file-exit-code' into maintLibravatar Junio C Hamano3-1/+38
"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
2015-11-03Merge branch 'dt/name-hash-dir-entry-fix' into maintLibravatar Junio C Hamano4-60/+35
The name-hash subsystem that is used to cope with case insensitive filesystems keeps track of directories and their on-filesystem cases for all the paths in the index by holding a pointer to a randomly chosen cache entry that is inside the directory (for its ce->ce_name component). This pointer was not updated even when the cache entry was removed from the index, leading to use after free. This was fixed by recording the path for each directory instead of borrowing cache entries and restructuring the API somewhat. * dt/name-hash-dir-entry-fix: name-hash: don't reuse cache_entry in dir_entry
2015-11-03Merge branch 'jc/am-3-fallback-regression-fix' into maintLibravatar Junio C Hamano1-16/+33
"git am -3" had a small regression where it is aborted in its error handling codepath when underlying merge-recursive failed in certain ways, as it assumed that the internal call to merge-recursive will never die, which is not the case (yet). * jc/am-3-fallback-regression-fix: am -3: do not let failed merge from completing the error codepath
2015-11-03Merge branch 'jc/usage-stdin' into maintLibravatar Junio C Hamano25-41/+64
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
2015-11-03Merge branch 'rt/placeholder-in-usage' into maintLibravatar Junio C Hamano2-3/+3
A couple of commands still showed "[options]" in their usage string to note where options should come on their command line, but we spell that "[<options>]" in most places these days. * rt/placeholder-in-usage: am, credential-cache: add angle brackets to usage string
2015-11-03Merge branch 'dt/t7063-fix-flaky-test' into maintLibravatar Junio C Hamano1-1/+3
* dt/t7063-fix-flaky-test: t7063: fix flaky untracked-cache test
2015-11-03Merge branch 'mk/submodule-gitdir-path' into maintLibravatar Junio C Hamano5-17/+42
The submodule code has been taught to work better with separate work trees created via "git worktree add". * mk/submodule-gitdir-path: path: implement common_dir handling in git_pathdup_submodule() submodule refactor: use strbuf_git_path_submodule() in add_submodule_odb()
2015-11-03Merge branch 'nd/gc-auto-background-fix' into maintLibravatar Junio C Hamano1-1/+55
When "git gc --auto" is backgrounded, its diagnosis message is lost. Save it to a file in $GIT_DIR and show it next time the "gc --auto" is run. * nd/gc-auto-background-fix: gc: save log from daemonized gc --auto and print it next time
2015-11-03Merge branch 'ls/p4-translation-failure' into maintLibravatar Junio C Hamano2-11/+66
Work around "git p4" failing when the P4 depot records the contents in UTF-16 without UTF-16 BOM. * ls/p4-translation-failure: git-p4: handle "Translation of file content failed" git-p4: add test case for "Translation of file content failed" error
2015-11-03Merge branch 'gr/rebase-i-drop-warn' into maintLibravatar Junio C Hamano2-0/+24
Recent update to "rebase -i" that tries to sanity check the edited insn sheet before it uses it has become too picky on Windows where CRLF left by the editor is turned into a trailing CR on the line read via the "read" built-in command. * gr/rebase-i-drop-warn: rebase-i: work around Windows CRLF line endings t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings
2015-11-03Merge branch 'js/clone-dissociate' into maintLibravatar Junio C Hamano4-23/+62
"git clone --dissociate" runs a big "git repack" process at the end, and it helps to close file descriptors that are open on the packs and their idx files before doing so on filesystems that cannot remove a file that is still open. * js/clone-dissociate: clone --dissociate: avoid locking pack files sha1_file.c: add a function to release all packs sha1_file: consolidate code to close a pack's file descriptor t5700: demonstrate a Windows file locking issue with `git clone --dissociate`
2015-11-03Merge branch 'ld/p4-import-labels' into maintLibravatar Junio C Hamano2-8/+62
Correct "git p4 --detect-labels" so that it does not fail to create a tag that points at a commit that is also being imported. * ld/p4-import-labels: git-p4: fix P4 label import for unprocessed commits git-p4: do not terminate creating tag for unknown commit git-p4: failing test for ignoring invalid p4 labels
2015-11-03Merge branch 'tk/stripspace' into maintLibravatar Junio C Hamano9-103/+118
The internal stripspace() function has been moved to where it logically belongs to, i.e. strbuf API, and the command line parser of "git stripspace" has been updated to use the parse_options API. * tk/stripspace: stripspace: use parse-options for command-line parsing strbuf: make stripspace() part of strbuf
2015-11-03Merge branch 'jk/repository-extension' into maintLibravatar Junio C Hamano8-12/+209
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
2015-11-02daemon: plug memory leakLibravatar René Scharfe1-0/+1
Call child_process_clear() when a child ends to release the memory allocated for its environment. This is necessary because unlike all other users of start_command() we don't call finish_command(), which would have taken care of that for us. This leak was introduced by f063d38b (daemon: use cld->env_array when re-spawning). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-02run-command: factor out child_process_clear()Libravatar René Scharfe3-6/+17
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>
2015-11-01wt-status: use skip_prefix() to get rid of magic string length constantsLibravatar René Scharfe1-21/+15
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: don't skip a magical number of characters blindlyLibravatar René Scharfe1-1/+1
Use the variable branch_name, which already has "refs/heads/" removed, instead of blindly advancing in the ->branch string by 11 bytes. This is safer and less magical. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: avoid building bogus branch name with detached HEADLibravatar René Scharfe2-7/+10
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes the string "HEAD (no branch)", translates it, skips the first eleven characters and passes the result to branch_get(), which returns a bogus result and accesses memory out of bounds in order to produce it. Somehow stat_tracking_info(), which is passed that result, does the right thing anyway, i.e. it finds that there is no base. Avoid the bogus results and memory accesses by checking for HEAD first and exiting early in that case. This fixes t7060 with --valgrind. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: exit early using goto in wt_shortstatus_print_tracking()Libravatar René Scharfe1-8/+5
Deduplicate printing the line terminator by jumping to the end of the function. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01t7060: add test for status --branch on a detached HEADLibravatar René Scharfe1-0/+14
This test fails when run under Valgrind because branch_get() gets passed a bogus branch name pointer: ==62831== Invalid read of size 1 ==62831== at 0x4F76AE: branch_get (remote.c:1650) ==62831== by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654) ==62831== by 0x53499E: wt_shortstatus_print (wt-status.c:1706) ==62831== by 0x428D29: cmd_status (commit.c:1384) ==62831== by 0x405D6D: run_builtin (git.c:350) ==62831== by 0x405D6D: handle_builtin (git.c:536) ==62831== by 0x404F10: run_argv (git.c:582) ==62831== by 0x404F10: main (git.c:690) ==62831== Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd ==62831== at 0x4C28C4F: malloc (vg_replace_malloc.c:299) ==62831== by 0x59579E9: strdup (strdup.c:42) ==62831== by 0x52E108: xstrdup (wrapper.c:43) ==62831== by 0x5322A6: wt_status_prepare (wt-status.c:130) ==62831== by 0x4276E0: status_init_config (commit.c:184) ==62831== by 0x428BB8: cmd_status (commit.c:1350) ==62831== by 0x405D6D: run_builtin (git.c:350) ==62831== by 0x405D6D: handle_builtin (git.c:536) ==62831== by 0x404F10: run_argv (git.c:582) ==62831== by 0x404F10: main (git.c:690) Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-29merge-file: clamp exit code to maximum 127Libravatar Jeff King3-1/+38
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>
2015-10-28rebase-i: work around Windows CRLF line endingsLibravatar Junio C Hamano2-1/+13
Editors on Windows can and do save text files with CRLF line endings, which is the convention on the platform. We are seeing reports that the "read" command in a port of bash to the environment however does not strip the CRLF at the end, not adjusting for the same convention on the platform. This breaks the recently added sanity checks for the insn sheet fed to "rebase -i"; instead of an empty line (hence nothing in $command), the script was getting a lone CR in there. Special case a lone CR and treat it the same way as an empty line to work this around. This patch (also) passes the test with Git for Windows, where the issue was seen first. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-28t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endingsLibravatar Johannes Schindelin1-0/+12
Based on a bug report by Chad Boles. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-28add_submodule_odb: initialize alt_odb list earlierLibravatar Jeff King1-1/+1
The add_submodule_odb function tries to add a submodule's object store as an "alternate". It needs the existing list to be initialized (from the objects/info/alternates file) for two reasons: 1. We look for duplicates with the existing alternate stores, but obviously this doesn't work if we haven't loaded any yet. 2. We link our new entry into the list by prepending it to alt_odb_list. But we do _not_ modify alt_odb_tail. This variable starts as NULL, and is a signal to the alt_odb code that the list has not yet been initialized. We then call read_info_alternates on the submodule (to recursively load its alternates), which will try to append to that tail, assuming it has been initialized. This causes us to segfault if it is NULL. This rarely comes up in practice, because we will have initialized the alt_odb any time we do an object lookup. So you can trigger this only when: - you try to access a submodule (e.g., a diff with diff.submodule=log) - the access happens before any other object has been accessed (e.g., because the diff is between the working tree and the index) - the submodule contains an alternates file (so we try to add an entry to the NULL alt_odb_tail) To fix this, we just need to call prepare_alt_odb at the start of the function (and if we have already initialized, it is a noop). Note that we can remove the prepare_alt_odb call from the end. It is guaranteed to be a noop, since we will have called it earlier. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26merge: detect delete/modechange conflictLibravatar Jeff King3-2/+37
If one side deletes a file and the other changes its content, we notice and report a conflict. However, if instead of changing the content, we change only the mode, the merge does not notice (and the mode change is silently dropped). The trivial index merge notices the problem and correctly leaves the conflict in the index, but both merge-recursive and merge-one-file will silently resolve this in favor of the deletion. In many cases that is a sane resolution, but we should be punting to the user whenever there is any question. So let's detect and treat this as a conflict (in both strategies). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26t6031: generalize for recursive and resolve strategiesLibravatar Jeff King2-56/+77
This script tests the filemode handling of merge-recursive, but we do not test the same thing for merge-resolve. Let's generalize the script a little: 1. Break out the setup steps for each test into a separate snippet. 2. For each test, run it twice; once with "-s recursive" and once with "-s resolve". We can avoid repeating ourselves by adding a function. 3. Since we have a nice abstracted function, we can make our tests more thorough by testing both directions (change on "ours" versus "theirs"). This improves our test coverage, and will make this the place to add more tests related to merging mode changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26t6031: move triple-rename test to t3030Libravatar Jeff King2-31/+30
The t6031 test was introduced to check filemode handling of merge-recursive. Much later, an unrelated test was tacked on to look at renames and d/f conflicts. This test does not depend on anything that happened before (it actually blows away any existing content in the test repo). Let's move it to t3030, where there are more related tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Correct fscanf formatting string for I64u valuesLibravatar Waldek Maleska2-1/+5
This fix is probably purely cosmetic because PRIuMAX is likely identical to SCNuMAX. Nevertheless, when using a function of the scanf() family, the correct interpolation to use is the latter, not the former. Signed-off-by: Waldek Maleska <w.maleska@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Silence GCC's "cast of pointer to integer of a different size" warningLibravatar Johannes Schindelin3-4/+6
When calculating hashes from pointers, it actually makes sense to cut off the most significant bits. In that case, said warning does not make a whole lot of sense. So let's just work around it by casting the pointer first to intptr_t and then casting up/down to the final integral type. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Squelch warning about an integer overflowLibravatar Johannes Schindelin1-1/+1
We cannot rely on long integers to have more than 32 bits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>