summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-07-11Merge branch 'sb/t5614-modernize' into maintLibravatar Junio C Hamano1-50/+20
Test clean-up. * sb/t5614-modernize: t5614: don't use subshells
2016-07-11Merge branch 'js/perf-on-apple' into maintLibravatar Junio C Hamano1-1/+5
t/perf needs /usr/bin/time with GNU extension; the invocation of it is updated to "gtime" on Darwin. * js/perf-on-apple: perf: accommodate for MacOSX
2016-07-11Merge branch 'ak/t7800-wo-readlink' into maintLibravatar Junio C Hamano1-1/+1
One among four invocations of readlink(1) in our test suite has been rewritten so that the test can run on systems without the command (others are in valgrind test framework and t9802). * ak/t7800-wo-readlink: t7800: readlink may not be available
2016-07-11Merge branch 'jk/tzoffset-fix' into maintLibravatar Junio C Hamano2-17/+69
The internal code used to show local timezone offset is not prepared to handle timestamps beyond year 2100, and gave a bogus offset value to the caller. Use a more benign looking +0000 instead and let "git log" going in such a case, instead of aborting. * jk/tzoffset-fix: local_tzoffset: detect errors from tm_to_time_t t0006: test various date formats t0006: rename test-date's "show" to "relative"
2016-07-11Merge branch 'sb/clone-shallow-passthru' into maintLibravatar Junio C Hamano1-2/+17
Fix an unintended regression in v2.9 that breaks "clone --depth" that recurses down to submodules by forcing the submodules to also be cloned shallowly, which many server instances that host upstream of the submodules are not prepared for. * sb/clone-shallow-passthru: clone: do not let --depth imply --shallow-submodules
2016-07-11Merge branch 'nd/graph-width-padded' into maintLibravatar Junio C Hamano1-0/+57
"log --graph --format=" learned that "%>|(N)" specifies the width relative to the terminal's left edge, not relative to the area to draw text that is to the right of the ancestry-graph section. It also now accepts negative N that means the column limit is relative to the right border. * nd/graph-width-padded: pretty.c: support <direction>|(<negative number>) forms pretty: pass graph width to pretty formatting for use in '%>|(N)'
2016-07-06Merge branch 'et/add-chmod-x' into maintLibravatar Junio C Hamano1-0/+30
"git update-index --add --chmod=+x file" may be usable as an escape hatch, but not a friendly thing to force for people who do need to use it regularly. "git add --chmod=+x file" can be used instead. * et/add-chmod-x: add: add --chmod=+x / --chmod=-x options
2016-07-06Merge branch 'sg/reflog-past-root' into maintLibravatar Junio C Hamano2-1/+23
"git reflog" stopped upon seeing an entry that denotes a branch creation event (aka "unborn"), which made it appear as if the reflog was truncated. * sg/reflog-past-root: reflog: continue walking the reflog past root commits
2016-06-27Merge branch 'rs/xdiff-hunk-with-func-line' into maintLibravatar Junio C Hamano7-77/+278
"git show -W" (extend hunks to cover the entire function, delimited by lines that match the "funcname" pattern) used to show the entire file when a change added an entire function at the end of the file, which has been fixed. * rs/xdiff-hunk-with-func-line: xdiff: fix merging of appended hunk with -W grep: -W: don't extend context to trailing empty lines t7810: add test for grep -W and trailing empty context lines xdiff: don't trim common tail with -W xdiff: -W: don't include common trailing empty lines in context xdiff: ignore empty lines before added functions with -W xdiff: handle appended chunks better with -W xdiff: factor out match_func_rec() t4051: rewrite, add more tests
2016-06-27Merge branch 'jk/rev-list-count-with-bitmap' into maintLibravatar Junio C Hamano1-0/+6
"git rev-list --count" whose walk-length is limited with "-n" option did not work well with the counting optimized to look at the bitmap index. * jk/rev-list-count-with-bitmap: rev-list: disable bitmaps when "-n" is used with listing objects rev-list: "adjust" results of "--count --use-bitmap-index -n"
2016-06-27Merge branch 'et/pretty-format-c-auto' into maintLibravatar Junio C Hamano1-7/+19
The commands in `git log` family take %C(auto) in a custom format string. This unconditionally turned the color on, ignoring --no-color or with --color=auto when the output is not connected to a tty; this was corrected to make the format truly behave as "auto". * et/pretty-format-c-auto: format_commit_message: honor `color=auto` for `%C(auto)`
2016-06-21t5614: don't use subshellsLibravatar Stefan Beller1-50/+20
Using a subshell for just one git command is both a waste in compute overhead (create a new process) as well as in line count. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7800: readlink may not be availableLibravatar Armin Kunaschik1-1/+1
The readlink(1) command is not available on all platforms (notably not on AIX and HP-UX) and can be replaced in this test with the "workaround" ls -ld <name> | sed -e 's/.* -> //' This is no universal readlink replacement but works in the controlled test environment well enough. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21perf: accommodate for MacOSXLibravatar Johannes Schindelin1-1/+5
As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And by the hard-coded path. Let's just work around this issue by using gtime on MacOSX, the Homebrew-provided GNU implementation onto which pretty much every MacOSX power user falls back anyway. To help other developers use Travis to run performance tests on MacOSX, the .travis.yml file now sports a commented-out line that installs GNU time via Homebrew. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20local_tzoffset: detect errors from tm_to_time_tLibravatar Jeff King1-0/+5
When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: test various date formatsLibravatar Jeff King1-0/+21
We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: rename test-date's "show" to "relative"Libravatar Jeff King1-13/+13
The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20clone: do not let --depth imply --shallow-submodulesLibravatar Junio C Hamano1-2/+17
In v2.9.0, we prematurely flipped the default to force cloning submodules shallowly, when the superproject is getting cloned shallowly. This is likely to fail when the upstream repositories submodules are cloned from a repository that is not prepared to serve histories that ends at a commit that is not at the tip of a branch, and we know the world is not yet ready. Use a safer default to clone the submodules fully, unless the user tells us that she knows that the upstream repository of the submodules are willing to cooperate with "--shallow-submodules" option. Noticed-by: Vadim Eisenberg <VADIME@il.ibm.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty.c: support <direction>|(<negative number>) formsLibravatar Nguyễn Thái Ngọc Duy1-0/+33
%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for that. Inspired by Go's array syntax (*). (*) I know Python has this first (or before Go, at least) but the idea didn't occur to me until I learned Go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty: pass graph width to pretty formatting for use in '%>|(N)'Libravatar Josef Kufner1-0/+24
Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-10Merge branch 'jk/shell-portability'Libravatar Junio C Hamano4-4/+25
test fixes. * jk/shell-portability: t5500 & t7403: lose bash-ism "local" test-lib: add in-shell "env" replacement
2016-06-10Merge branch 'jc/t2300-setup'Libravatar Junio C Hamano1-1/+2
A test fix. * jc/t2300-setup: t2300: run git-sh-setup in an environment that better mimics the real life
2016-06-09xdiff: fix merging of appended hunk with -WLibravatar René Scharfe1-1/+23
When -W is given we search the lines between the end of the current context and the next change for a function line. If there is none then we merge those two hunks as they must be part of the same function. If the next change is an appended chunk we abort the search early in get_func_line(), however, because its line number is out of range. Fix that by searching from the end of the pre-image in that case instead. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-07add: add --chmod=+x / --chmod=-x optionsLibravatar Edward Thomson1-0/+30
The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06reflog: continue walking the reflog past root commitsLibravatar SZEDER Gábor2-1/+23
If a repository contains more than one root commit, then its HEAD reflog may contain multiple "creation events", i.e. entries whose "from" value is the null sha1. Listing such a reflog currently stops prematurely at the first such entry, even when the reflog still contains older entries. This can scare users into thinking that their reflog got truncated after 'git checkout --orphan'. Continue walking the reflog past such creation events based on the preceeding reflog entry's "new" value. The test 'symbolic-ref writes reflog entry' in t1401-symbolic-ref implicitly relies on the current behavior of the reflog walker to stop at a root commit and thus to list only the reflog entries that are relevant for that test. Adjust the test to explicitly specify the number of relevant reflog entries to be listed. Reported-by: Patrik Gustafsson <pvn@textalk.se> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03Merge branch 'js/perf-rebase-i'Libravatar Junio C Hamano1-1/+4
The one in 'master' has a brown-paper-bag bug that breaks the perf test when used inside a usual Git repository with a working tree. * js/perf-rebase-i: perf: make the tests work without a worktree
2016-06-03rev-list: "adjust" results of "--count --use-bitmap-index -n"Libravatar Jeff King1-0/+6
If you ask rev-list for: git rev-list --count --use-bitmap-index HEAD we optimize out the actual traversal and just give you the number of bits set in the commit bitmap. This is faster, which is good. But if you ask to limit the size of the traversal, like: git rev-list --count --use-bitmap-index -n 100 HEAD we'll still output the full bitmapped number we found. On the surface, that might even seem OK. You explicitly asked to use the bitmap index, and it was cheap to compute the real answer, so we gave it to you. But there's something much more complicated going on under the hood. If we don't have a bitmap directly for HEAD, then we have to actually traverse backwards, looking for a bitmapped commit. And _that_ traversal is bounded by our `-n` count. This is a good thing, because it bounds the work we have to do, which is probably what the user wanted by asking for `-n`. But now it makes the output quite confusing. You might get many values: - your `-n` value, if we walked back and never found a bitmap (or fewer if there weren't that many commits) - the actual full count, if we found a bitmap root for every path of our traversal with in the `-n` limit - any number in between! We might have walked back and found _some_ bitmaps, but then cut off the traversal early with some commits not accounted for in the result. So you cannot even see a value higher than your `-n` and say "OK, bitmaps kicked in, this must be the real full count". The only sane thing is for git to just clamp the value to a maximum of the `-n` value, which means we should output the exact same results whether bitmaps are in use or not. The test in t5310 demonstrates this by using `-n 1`. Without this patch we fail in the full-bitmap case (where we do not have to traverse at all) but _not_ in the partial-bitmap case (where we have to walk down to find an actual bitmap). With this patch, both cases just work. I didn't implement the crazy in-between case, just because it's complicated to set up, and is really a subset of the full-count case, which we do cover. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01t2300: run git-sh-setup in an environment that better mimics the real lifeLibravatar Junio C Hamano1-1/+2
When we run scripted Porcelains, "git" potty has set up the $PATH by prepending $GIT_EXEC_PATH, the path given by "git --exec-path=$there $cmd", etc. already. Because of this, scripted Porcelains can dot-source shell script library like git-sh-setup with simple dot without specifying any path. t2300 however dot-sources git-sh-setup without adjusting $PATH like the real "git" potty does. This has not been a problem so far, but once git-sh-setup wants to rely on the $PATH adjustment, just like any scripted Porcelains already do, it would become one. It cannot for example dot-source another shell library without specifying the full path to it by prefixing $(git --exec-path). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01t5500 & t7403: lose bash-ism "local"Libravatar Junio C Hamano2-3/+2
In t5500::check_prot_host_port_path(), diagport is not a variable used elsewhere and the function is not recursively called so this can simply lose the "local", which may not be supported by shell (besides, the function liberally clobbers other variables without making them "local"). t7403::reset_submodule_urls() overrides the "root" variable used in the test framework for no good reason; its use is not about temporarily relocating where the test repositories are created. This assignment can be made not to clobber the variable by moving them into the subshells it already uses. Its value is always $TRASH_DIRECTORY, so we could use it instead there, and this function that is called only once and its two subshells may not be necessary (instead, the caller can use "git -C $there config" and set a value that is derived from $TRASH_DIRECTORY), but this is a minimum fix that is needed to lose "local". Helped-by: John Keeping <john@keeping.me.uk> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01test-lib: add in-shell "env" replacementLibravatar Jeff King2-1/+23
The one-shot environment variable syntax: FOO=BAR some-program is unportable when some-program is actually a shell function, like test_must_fail (on some shells FOO remains set after the function returns, and on others it does not). We sometimes get around this by using env, like: test_must_fail env FOO=BAR some-program But that only works because test_must_fail's arguments are themselves a command which can be run. You can't run: env FOO=BAR test_must_fail some-program because env does not know about our shell functions. So there is no equivalent for test_commit, for example, and one must resort to: ( FOO=BAR export FOO test_commit ) which is a bit verbose. Let's add a version of "env" that works _inside_ the shell, by creating a subshell, exporting variables from its argument list, and running the command. Its use is demonstrated on a currently-unportable case in t4014. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31Merge branch 'sb/submodule-deinit-all' into maintLibravatar Junio C Hamano1-1/+23
Correct faulty recommendation to use "git submodule deinit ." when de-initialising all submodules, which would result in a strange error message in a pathological corner case. * sb/submodule-deinit-all: submodule deinit: require '--all' instead of '.' for all submodules
2016-05-31Merge branch 'jk/test-send-sh-x-trace-elsewhere' into maintLibravatar Junio C Hamano2-3/+16
Running tests with '-x' option to trace the individual command executions is a useful way to debug test scripts, but some tests that capture the standard error stream and check what the command said can be broken with the trace output mixed in. When running our tests under "bash", however, we can redirect the trace output to another file descriptor to keep the standard error of programs being tested intact. * jk/test-send-sh-x-trace-elsewhere: test-lib: set BASH_XTRACEFD automatically
2016-05-31Merge branch 'js/name-rev-use-oldest-ref' into maintLibravatar Junio C Hamano1-1/+1
"git describe --contains" often made a hard-to-justify choice of tag to give name to a given commit, because it tried to come up with a name with smallest number of hops from a tag, causing an old commit whose close descendant that is recently tagged were not described with respect to an old tag but with a newer tag. It did not help that its computation of "hop" count was further tweaked to penalize being on a side branch of a merge. The logic has been updated to favor using the tag with the oldest tagger date, which is a lot easier to explain to the end users: "We describe a commit in terms of the (chronologically) oldest tag that contains the commit." * js/name-rev-use-oldest-ref: name-rev: include taggerdate in considering the best name
2016-05-31perf: make the tests work without a worktreeLibravatar René Scharfe1-1/+4
In regular repositories $source_git and $objects_dir contain relative paths based on $source. Go there to allow cp to resolve them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31grep: -W: don't extend context to trailing empty linesLibravatar René Scharfe1-1/+1
Empty lines between functions are shown by grep -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patches stopped showing them for diff -W. Stop showing empty lines trailing a function with grep -W. Grep scans the lines of a buffer from top to bottom and prints matching lines immediately. Thus we need to peek ahead in order to determine if an empty line is part of a function body and worth showing or not. Remember how far ahead we peeked in order to avoid having to do so repeatedly when handling multiple consecutive empty lines. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31t7810: add test for grep -W and trailing empty context linesLibravatar René Scharfe1-3/+16
Add a test demonstrating that git grep -W prints empty lines following the function context we're actually interested in. The modified test file makes it necessary to adjust three unrelated test cases. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31xdiff: don't trim common tail with -WLibravatar René Scharfe1-1/+1
The function trim_common_tail() exits early if context lines are requested. If -U0 and -W are specified together then it can still trim context lines that might belong to a changed function. As a result that function is shown incompletely. Fix that by calling trim_common_tail() only if no function context or fixed context is requested. The parameter ctx is no longer needed now; remove it. While at it fix an outdated comment as well. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31xdiff: -W: don't include common trailing empty lines in contextLibravatar René Scharfe1-2/+2
Empty lines between functions are shown by diff -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patch stopped showing them in the special case of a function added at the end of a file. Stop extending context to those empty lines by skipping back over them from the start of the next function. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31xdiff: ignore empty lines before added functions with -WLibravatar René Scharfe1-1/+1
If a new function and a preceding empty line is appended, diff -W shows the previous function in full in order to provide context for that empty line. In most languages empty lines between sections are not interesting in and off themselves and showing a whole extra function for them is not what we want. Skip empty lines when checking of the appended chunk starts with a function line, thereby avoiding to extend the context just for them. Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31xdiff: handle appended chunks better with -WLibravatar René Scharfe1-1/+1
If lines are added at the end of a file, diff -W shows the whole file. That's because get_func_line() only considers the pre-image and gives up if it sees a record index beyond its end. Consider the post-image as well to see if the added lines already make up a full function. If it doesn't then search for the previous function line by starting from the bottom of the pre-image, thereby avoiding to confuse get_func_line(). Reuse the existing label called "again", as it's exactly where we need to jump to when we're done handling the pre-context, but rename it to "post_context_calculation" in order to document its new purpose better. Reported-by: Junio C Hamano <gitster@pobox.com> Initial-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31t4051: rewrite, add more testsLibravatar René Scharfe6-74/+240
Remove the tests that checked against a fixed result and replace them with more focused checks of desired properties of the created diffs. That way we get more detailed and meaningful diagnostics. Store test file contents in files in a subdirectory in order to avoid cluttering the test script with them. Use tagged commits to store the changes to test diff -W against instead of using changes to the worktree. Use the worktree instead to try and apply the generated patch in order to validate it. Document unwanted features: trailing empty lines, too much context for appended functions, insufficient context at the end with -U0. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31Merge branch 'es/t1500-modernize'Libravatar Junio C Hamano1-60/+63
test updates to make it more readable and maintainable. * es/t1500-modernize: t1500: avoid setting environment variables outside of tests t1500: avoid setting configuration options outside of tests t1500: avoid changing working directory outside of tests t1500: test_rev_parse: facilitate future test enhancements t1500: be considerate to future potential tests
2016-05-31Merge branch 'fc/fast-import-broken-marks-file'Libravatar Junio C Hamano1-0/+15
"git fast-import --export-marks" would overwrite the existing marks file even when it makes a dump from its custom die routine. Prevent it from doing so when we have an import-marks file but haven't finished reading it. * fc/fast-import-broken-marks-file: fast-import: do not truncate exported marks file
2016-05-29Merge branch 'ak/t0008-ksh88-workaround'Libravatar Junio C Hamano1-2/+2
Test portability workaround. * ak/t0008-ksh88-workaround: t0008: 4 tests fail with ksh88
2016-05-29Merge branch 'js/t6044-use-test-seq'Libravatar Junio C Hamano1-2/+2
Test portability fix. * js/t6044-use-test-seq: t6044: replace seq by test_seq
2016-05-27format_commit_message: honor `color=auto` for `%C(auto)`Libravatar Edward Thomson1-7/+19
git-log(1) documents that when specifying the `%C(auto)` format placeholder will "turn on auto coloring on the next %placeholders until the color is switched again." However, when `%C(auto)` is used, the present implementation will turn colors on unconditionally (even if the color configuration is turned off for the current context - for example, `--no-color` was specified or the color is `auto` and the output is not a tty). Update `format_commit_one` to examine the current context when a format string of `%C(auto)` is specified, which ensures that we will not unconditionally write colors. This brings that behavior in line with the behavior of `%C(auto,<colorname>)`, and allows the user the ability to specify that color should be displayed only when the output is a tty. Additionally, add a test for `%C(auto)` and update the existing tests for `%C(auto,...)` as they were misidentified as being applicable to `%C(auto)`. Tests from Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'jc/fsck-nul-in-commit' into maintLibravatar Junio C Hamano1-0/+18
"git fsck" learned to catch NUL byte in a commit object as potential error and warn. * jc/fsck-nul-in-commit: fsck: detect and warn a commit with embedded NUL fsck_commit_buffer(): do not special case the last validation
2016-05-26Merge branch 'js/windows-dotgit' into maintLibravatar Junio C Hamano2-0/+50
On Windows, .git and optionally any files whose name starts with a dot are now marked as hidden, with a core.hideDotFiles knob to customize this behaviour. * js/windows-dotgit: mingw: remove unnecessary definition mingw: introduce the 'core.hideDotFiles' setting
2016-05-26Merge branch 'lp/typofixes' into maintLibravatar Junio C Hamano1-1/+1
Typofixes. * lp/typofixes: typofix: assorted typofixes in comments, documentation and messages
2016-05-26Merge branch 'sb/z-is-gnutar-ism' into maintLibravatar Junio C Hamano2-4/+4
Test fix. * sb/z-is-gnutar-ism: t6041: do not compress backup tar file t3513: do not compress backup tar file