summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-03-21Merge branch 'jh/send-email-one-cc' into maintLibravatar Junio C Hamano1-4/+3
"Cc:" on the trailer part does not have to conform to RFC strictly, unlike in the e-mail header. "git send-email" has been updated to ignore anything after '>' when picking addresses, to allow non-address cruft like " # stable 4.4" after the address. * jh/send-email-one-cc: send-email: only allow one address per body tag
2017-03-21Merge branch 'jk/t6300-cleanup' into maintLibravatar Junio C Hamano1-1/+1
A test that creates a confusing branch whose name is HEAD has been corrected not to do so. * jk/t6300-cleanup: t6300: avoid creating refs/heads/HEAD
2017-03-21Merge branch 'rl/remote-allow-missing-branch-name-merge' into maintLibravatar Junio C Hamano1-0/+19
"git remote rm X", when a branch has remote X configured as the value of its branch.*.remote, tried to remove branch.*.remote and branch.*.merge and failed if either is unset. * rl/remote-allow-missing-branch-name-merge: remote: ignore failure to remove missing branch.<name>.merge
2017-03-21Merge branch 'dt/gc-ignore-old-gc-logs' into maintLibravatar Junio C Hamano1-0/+15
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-03-21Merge branch 'jc/diff-populate-filespec-size-only-fix' into maintLibravatar Junio C Hamano1-0/+9
"git diff --quiet" relies on the size field in diff_filespec to be correctly populated, but diff_populate_filespec() helper function made an incorrect short-cut when asked only to populate the size field for paths that need to go through convert_to_git() (e.g. CRLF conversion). * jc/diff-populate-filespec-size-only-fix: diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()
2017-03-16Merge branch 'js/realpath-pathdup-fix' into maintLibravatar Junio C Hamano1-0/+8
Git v2.12 was shipped with an embarrassing breakage where various operations that verify paths given from the user stopped dying when seeing an issue, and instead later triggering segfault. ... and then to down to 'maint'. * js/realpath-pathdup-fix: real_pathdup(): fix callsites that wanted it to die on error t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE
2017-03-16Merge branch 'ax/line-log-range-merge-fix' into maintLibravatar Junio C Hamano1-0/+10
The code to parse "git log -L..." command line was buggy when there are many ranges specified with -L; overrun of the allocated buffer has been fixed. * ax/line-log-range-merge-fix: line-log.c: prevent crash during union of too many ranges
2017-03-16Merge branch 'jk/add-i-patch-do-prompt' into maintLibravatar Junio C Hamano1-0/+18
The patch subcommand of "git add -i" was meant to have paths selection prompt just like other subcommand, unlike "git add -p" directly jumps to hunk selection. Recently, this was broken and "add -i" lost the paths selection dialog, but it now has been fixed. * jk/add-i-patch-do-prompt: add--interactive: fix missing file prompt for patch mode with "-i"
2017-03-08real_pathdup(): fix callsites that wanted it to die on errorLibravatar Johannes Schindelin1-1/+1
In 4ac9006f832 (real_path: have callers use real_pathdup and strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) pattern to use real_pathdup() directly. The problem with this change is that real_path() calls strbuf_realpath() with die_on_error = 1 while real_pathdup() calls it with die_on_error = 0. Meaning that in cases where real_path() causes Git to die() with an error message, real_pathdup() is silent and returns NULL instead. The callers, however, are ill-prepared for that change, as they expect the return value to be non-NULL (and otherwise the function died with an appropriate error message). Fix this by extending real_pathdup()'s signature to accept the die_on_error flag and simply pass it through to strbuf_realpath(), and then adjust all callers after a careful audit whether they would handle NULLs well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-08t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREELibravatar Johannes Schindelin1-0/+8
When GIT_WORK_TREE does not specify a valid path, we should error out, instead of crashing. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-03line-log.c: prevent crash during union of too many rangesLibravatar Allan Xavier1-0/+10
The existing implementation of range_set_union does not correctly reallocate memory, leading to a heap overflow when it attempts to union more than 24 separate line ranges. For struct range_set *out to grow correctly it must have out->nr set to the current size of the buffer when it is passed to range_set_grow. However, the existing implementation of range_set_union only updates out->nr at the end of the function, meaning that it is always zero before this. This results in range_set_grow never growing the buffer, as well as some of the union logic itself being incorrect as !out->nr is always true. The reason why 24 is the limit is that the first allocation of size 1 ends up allocating a buffer of size 24 (due to the call to alloc_nr in ALLOC_GROW). This goes some way to explain why this hasn't been caught before. Fix the problem by correctly updating out->nr after reallocating the range_set. As this results in out->nr containing the same value as the variable o, replace o with out->nr as well. Finally, add a new test to help prevent the problem reoccurring in the future. Thanks to Vegard Nossum for writing the test. Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()Libravatar Junio C Hamano1-0/+9
Callers of diff_populate_filespec() can choose to ask only for the size of the blob without grabbing the blob data, and the function, after running lstat() when the filespec points at a working tree file, returns by copying the value in size field of the stat structure into the size field of the filespec when this is the case. However, this short-cut cannot be taken if the contents from the path needs to go through convert_to_git(), whose resulting real blob data may be different from what is in the working tree file. As "git diff --quiet" compares the .size fields of filespec structures to skip content comparison, this bug manifests as a false "there are differences" for a file that needs eol conversion, for example. Reported-by: Mike Crowe <mac@mcrowe.com> Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02add--interactive: fix missing file prompt for patch mode with "-i"Libravatar Jeff King1-0/+18
When invoked as "git add -i", each menu interactive menu option prompts the user to select a list of files. This includes the "patch" option, which gets the list before starting the hunk-selection loop. As "git add -p", it behaves differently, and jumps straight to the hunk selection loop. Since 0539d5e6d (i18n: add--interactive: mark patch prompt for translation, 2016-12-14), the "add -i" case mistakenly jumps to straight to the hunk-selection loop. Prior to that commit the distinction between the two cases was managed by the $patch_mode variable. That commit used $patch_mode for something else, and moved the old meaning to the "$cmd" variable. But it forgot to update the $patch_mode check inside patch_update_cmd() which controls the file-list behavior. The simplest fix would be to change that line to check $cmd. But while we're here, let's use a less obscure name for this flag: $patch_mode_only, a boolean which tells whether we are in full-interactive mode or only in patch-mode. Reported-by: Henrik Grubbström <grubba@grubba.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28http: attempt updating base URL only if no errorLibravatar Jonathan Tan2-0/+18
http.c supports HTTP redirects of the form http://foo/info/refs?service=git-upload-pack -> http://anything -> http://bar/info/refs?service=git-upload-pack (that is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the intermediate steps can have any URL). However, if one of the intermediate steps results in an HTTP exception, a confusing "unable to update url base from redirection" message is printed instead of a Curl error message with the HTTP exception code. This was introduced by 2 commits. Commit c93c92f ("http: update base URLs when we see redirects", 2013-09-28) introduced a best-effort optimization that required checking if only the "base" part of the URL differed between the initial request and the final redirect destination, but it performed the check before any HTTP status checking was done. If something went wrong, the normal code path was still followed, so this did not cause any confusing error messages until commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06), which taught http to die if the non-"base" part of the URL differed. Therefore, teach http to check the HTTP status before attempting to check if only the "base" part of the URL differed. This commit teaches http_request_reauth to return early without updating options->base_url upon an error; the only invoker of this function that passes a non-NULL "options" is remote-curl.c (through "http_get_strbuf"), which only uses options->base_url for an informational message in the situations that this commit cares about (that is, when the return value is not HTTP_OK). The included test checks that the redirect scheme at the beginning of this commit message works, and that returning a 502 in the middle of the redirect scheme produces the correct result. Note that this is different from the test in commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06) in that this commit tests that a Git-shaped URL (http://.../info/refs?service=git-upload-pack) works, whereas commit 6628eb4 tests that a non-Git-shaped URL (http://.../info/refs/foo?service=git-upload-pack) does not work (even though Git is processing that URL) and is an error that is fatal, not silently swallowed. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27t6300: avoid creating refs/heads/HEADLibravatar Jeff King1-1/+1
In one test, we use "git checkout --orphan HEAD" to create an unborn branch. Confusingly, the resulting branch is named "refs/heads/HEAD". The original probably meant something like: git checkout --orphan orphaned-branch HEAD Let's just use "orphaned-branch" here to make this less confusing. Putting HEAD in the second argument is already implied. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27send-email: only allow one address per body tagLibravatar Johan Hovold1-4/+3
Adding comments after a tag in the body is a common practise (e.g. in the Linux kernel) and git-send-email has been supporting this for years by removing any trailing cruft after the address. After some recent changes, any trailing comment is now instead appended to the recipient name (with some random white space inserted) resulting in undesirable noise in the headers, for example: CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org> Revert to the earlier behaviour of discarding anything after the (first) address in a tag while parsing the body. Note that multiple addresses after are still allowed after a command line switch (and in a CC header field). Also note that --suppress-cc=self was never honoured when using multiple addresses in a tag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-21remote: ignore failure to remove missing branch.<name>.mergeLibravatar Ross Lagerwall1-0/+19
It is not all too unusual for a branch to use "branch.<name>.remote" without "branch.<name>.merge". You may be using the 'push.default' configuration set to 'current', for example, and do $ git checkout -b side colleague/side $ git config branch.side.remote colleague However, "git remote rm" to remove the remote used in such a manner fails with "fatal: could not unset 'branch.<name>.merge'" because it assumes that a branch that has .remote defined must also have .merge defined. Detect the "cannot unset because it is not set to begin with" case and ignore it. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-16Merge branch 'ls/p4-path-encoding'Libravatar Junio C Hamano1-0/+16
When "git p4" imports changelist that removes paths, it failed to convert pathnames when the p4 used encoding different from the one used on the Git side. This has been corrected. * ls/p4-path-encoding: git-p4: fix git-p4.pathEncoding for removed files
2017-02-15Merge branch 'sb/push-options-via-transport'Libravatar Junio C Hamano1-0/+15
The push-options given via the "--push-options" option were not passed through to external remote helpers such as "smart HTTP" that are invoked via the transport helper. * sb/push-options-via-transport: push options: pass push options to the transport helper
2017-02-13gc: ignore old gc.log filesLibravatar David Turner1-0/+15
A server can end up in a state where there are lots of unreferenced loose objects (say, because many users are doing a bunch of rebasing and pushing their rebased branches). Running "git gc --auto" in this state would cause a gc.log file to be created, preventing future auto gcs, causing pack files to pile up. Since many git operations are O(n) in the number of pack files, this would lead to poor performance. Git should never get itself into a state where it refuses to do any maintenance, just because at some point some piece of the maintenance didn't make progress. Teach Git to ignore gc.log files which are older than (by default) one day old, which can be tweaked via the gc.logExpiry configuration variable. That way, these pack files will get cleaned up, if necessary, at least once per day. And operators who find a need for more-frequent gcs can adjust gc.logExpiry to meet their needs. There is also some cleanup: a successful manual gc, or a warning-free auto gc with an old log file, will remove any old gc.log files. It might still happen that manual intervention is required (e.g. because the repo is corrupt), but at the very least it won't be because Git is too dumb to try again. Signed-off-by: David Turner <dturner@twosigma.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10git-p4: fix git-p4.pathEncoding for removed filesLibravatar Lars Schneider1-0/+16
In a9e38359e3 we taught git-p4 a way to re-encode path names from what was used in Perforce to UTF-8. This path re-encoding worked properly for "added" paths. "Removed" paths were not re-encoded and therefore different from the "added" paths. Consequently, these files were not removed in a git-p4 cloned Git repository because the path names did not match. Fix this by moving the re-encoding to a place that affects "added" and "removed" paths. Add a test to demonstrate the issue. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10Merge branch 'jk/log-graph-name-only'Libravatar Junio C Hamano1-0/+48
"git log --graph" did not work well with "--name-only", even though other forms of "diff" output were handled correctly. * jk/log-graph-name-only: diff: print line prefix for --name-only output
2017-02-10Merge branch 'da/t7800-cleanup'Libravatar Junio C Hamano1-12/+19
Test updates. * da/t7800-cleanup: t7800: replace "wc -l" with test_line_count
2017-02-10Merge branch 'js/difftool-builtin'Libravatar Junio C Hamano1-0/+12
A few hot-fixes to C-rewrite of "git difftool". * js/difftool-builtin: t7800: simplify basic usage test difftool: fix bug when printing usage
2017-02-10Merge branch 'rs/p5302-create-repositories-before-tests'Libravatar Junio C Hamano1-0/+7
Adjust a perf test to new world order where commands that do require a repository are really strict about having a repository. * rs/p5302-create-repositories-before-tests: p5302: create repositories for index-pack results explicitly
2017-02-08push options: pass push options to the transport helperLibravatar Stefan Beller1-0/+15
When using non-builtin protocols relying on a transport helper (such as http), push options are not propagated to the helper. The user could ask for push options and a push would seemingly succeed, but the push options would never be transported to the server, misleading the users expectation. Fix this by propagating the push options to the transport helper. This is only addressing the first issue of (1) the helper protocol does not propagate push-option (2) the http helper is not prepared to handle push-option Once we fix (2), the http transport helper can make use of push options as well, but that happens as a follow up. (1) is a bug fix, whereas (2) is a feature, which is why we only do (1) here. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08diff: print line prefix for --name-only outputLibravatar Jeff King1-0/+48
If you run "git log --graph --name-only", the pathnames are not indented to go along with their matching commits (unlike all of the other diff formats). We need to output the line prefix for each item before writing it. The tests cover both --name-status and --name-only. The former actually gets this right already, because it builds on the --raw format functions. It's only --name-only which uses its own code (and this fix mirrors the code in diff_flush_raw()). Note that the tests don't follow our usual style of setting up the "expect" output inside the test block. This matches the surrounding style, but more importantly it is easier to read: we don't have to worry about embedded single-quotes, and the leading indentation is more obvious. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08t7800: replace "wc -l" with test_line_countLibravatar David Aguilar1-12/+19
Make t7800 easier to debug by capturing output into temporary files and using test_line_count to make assertions on those files. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08Merge branch 'da/difftool-dir-diff-fix' into da/t7800-cleanupLibravatar Junio C Hamano1-3/+41
* da/difftool-dir-diff-fix: difftool: fix dir-diff index creation when in a subdirectory
2017-02-08t7800: simplify basic usage testLibravatar David Aguilar1-8/+7
Use "test_line_count" instead of "wc -l", use "git -C" instead of a subshell, and use test_expect_code when calling difftool. Ease debugging by capturing output into temporary files. Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-06p5302: create repositories for index-pack results explicitlyLibravatar René Scharfe1-0/+7
Before 7176a314 (index-pack: complain when --stdin is used outside of a repo) index-pack silently created a non-existing target directory; now the command refuses to work unless it's used against a valid repository. That causes p5302 to fail, which relies on the former behavior. Fix it by setting up the destinations for its performance tests using git init. Signed-off-by: Rene Scharfe <l.s.r@web.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-06difftool: fix bug when printing usageLibravatar David Aguilar1-0/+13
"git difftool -h" reports an error: fatal: BUG: setup_git_env called without repository Defer repository setup so that the help option processing happens before the repository is initialized. Add tests to ensure that the basic usage works inside and outside of a repository. Signed-off-by: David Aguilar <davvid@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03Merge branch 'cw/log-updates-for-all-refs-really'Libravatar Junio C Hamano2-7/+81
The "core.logAllRefUpdates" that used to be boolean has been enhanced to take 'always' as well, to record ref updates to refs other than the ones that are expected to be updated (i.e. branches, remote-tracking branches and notes). * cw/log-updates-for-all-refs-really: doc: add note about ignoring '--no-create-reflog' update-ref: add test cases for bare repository refs: add option core.logAllRefUpdates = always config: add markup to core.logAllRefUpdates doc
2017-02-03Merge branch 'js/re-running-failed-tests'Libravatar Junio C Hamano1-0/+6
"make -C t failed" will now run only the tests that failed in the previous run. This is usable only when prove is not use, and gives a useless error message when run after "make clean", but otherwise is serviceable. * js/re-running-failed-tests: t/Makefile: add a rule to re-run previously-failed tests
2017-02-03Merge branch 'sb/submodule-update-initial-runs-custom-script'Libravatar Junio C Hamano1-0/+12
The user can specify a custom update method that is run when "submodule update" updates an already checked out submodule. This was ignored when checking the submodule out for the first time and we instead always just checked out the commit that is bound to the path in the superproject's index. * sb/submodule-update-initial-runs-custom-script: submodule update: run custom update script for initial populating as well
2017-02-03Merge branch 'sb/submodule-recursive-absorb'Libravatar Junio C Hamano1-0/+27
When a submodule "A", which has another submodule "B" nested within it, is "absorbed" into the top-level superproject, the inner submodule "B" used to be left in a strange state. The logic to adjust the .git pointers in these submodules has been corrected. * sb/submodule-recursive-absorb: submodule absorbing: fix worktree/gitdir pointers recursively for non-moves cache.h: expose the dying procedure for reading gitlinks setup: add gentle version of resolve_git_dir
2017-02-03Merge branch 'sb/unpack-trees-super-prefix'Libravatar Junio C Hamano2-654/+643
"git read-tree" and its underlying unpack_trees() machinery learned to report problematic paths prefixed with the --super-prefix option. * sb/unpack-trees-super-prefix: unpack-trees: support super-prefix option t1001: modernize style t1000: modernize style read-tree: use OPT_BOOL instead of OPT_SET_INT
2017-02-02Merge branch 'nd/log-graph-configurable-colors'Libravatar Junio C Hamano3-1/+42
Some people feel the default set of colors used by "git log --graph" rather limiting. A mechanism to customize the set of colors has been introduced. * nd/log-graph-configurable-colors: document behavior of empty color name color_parse_mem: allow empty color spec log --graph: customize the graph lines with config log.graphColors color.c: trim leading spaces in color_parse_mem() color.c: fix color_parse_mem() with value_len == 0
2017-02-02Merge branch 'mm/reset-facl-before-umask-test'Libravatar Junio C Hamano1-0/+3
Test tweaks for those who have default ACL in their git source tree that interfere with the umask test. * mm/reset-facl-before-umask-test: t0001: don't let a default ACL interfere with the umask test
2017-02-02Merge branch 'js/unzip-in-usr-bin-workaround'Libravatar Junio C Hamano1-1/+3
Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run our tests but /usr/local/bin/unzip is usable. * js/unzip-in-usr-bin-workaround: test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/
2017-02-02Merge branch 'js/status-pre-rebase-i'Libravatar Junio C Hamano1-0/+19
After starting "git rebase -i", which first opens the user's editor to edit the series of patches to apply, but before saving the contents of that file, "git status" failed to show the current state (i.e. you are in an interactive rebase session, but you have applied no steps yet) correctly. * js/status-pre-rebase-i: status: be prepared for not-yet-started interactive rebase
2017-02-02Merge branch 'sb/submodule-add-force'Libravatar Junio C Hamano1-0/+14
"git submodule add" used to be confused and refused to add a locally created repository; users can now use "--force" option to add them. * sb/submodule-add-force: submodule add: extend force flag to add existing repos
2017-01-31color_parse_mem: allow empty color specLibravatar Jeff King3-2/+21
Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31Merge branch 'jk/grep-e-could-be-extended-beyond-posix' into maintLibravatar Junio C Hamano1-11/+15
Tighten a test to avoid mistaking an extended ERE regexp engine as a PRE regexp engine. * jk/grep-e-could-be-extended-beyond-posix: t7810: avoid assumption about invalid regex syntax
2017-01-31Merge branch 'km/branch-get-push-while-detached' into maintLibravatar Junio C Hamano1-0/+6
"git <cmd> @{push}" on a detached HEAD used to segfault; it has been corrected to error out with a message. * km/branch-get-push-while-detached: branch_get_push: do not segfault when HEAD is detached
2017-01-31Merge branch 'jk/blame-fixes' into maintLibravatar Junio C Hamano2-0/+149
"git blame --porcelain" misidentified the "previous" <commit, path> pair (aka "source") when contents came from two or more files. * jk/blame-fixes: blame: output porcelain "previous" header for each file blame: handle --no-abbrev blame: fix alignment with --abbrev=40
2017-01-31Merge branch 'jk/archive-zip-userdiff-config' into maintLibravatar Junio C Hamano1-4/+18
"git archive" did not read the standard configuration files, and failed to notice a file that is marked as binary via the userdiff driver configuration. * jk/archive-zip-userdiff-config: archive-zip: load userdiff config
2017-01-31Merge branch 'dt/disable-bitmap-in-auto-gc' into maintLibravatar Junio C Hamano2-5/+28
It is natural that "git gc --auto" may not attempt to pack everything into a single pack, and there is no point in warning when the user has configured the system to use the pack bitmap, leading to disabling further "gc". * dt/disable-bitmap-in-auto-gc: repack: die on incremental + write-bitmap-index auto gc: don't write bitmaps for incremental repacks
2017-01-31Merge branch 'mh/fast-import-notes-fix-new' into maintLibravatar Junio C Hamano1-0/+42
"git fast-import" sometimes mishandled while rebalancing notes tree, which has been fixed. * mh/fast-import-notes-fix-new: fast-import: properly fanout notes when tree is imported
2017-01-31Merge branch 'jc/compression-config' into maintLibravatar Junio C Hamano3-0/+140
Compression setting for producing packfiles were spread across three codepaths, one of which did not honor any configuration. Unify these so that all of them honor core.compression and pack.compression variables the same way. * jc/compression-config: compression: unify pack.compression configuration parsing