git/t, branch v2.4.7

Merge branch 'jk/rev-list-no-bitmap-while-pruning' into maint

2015-07-27T19:21:42Z

A minor bugfix when pack bitmap is used with "rev-list --count". * jk/rev-list-no-bitmap-while-pruning: rev-list: disable --use-bitmap-index when pruning commits

Merge branch 'rh/test-color-avoid-terminfo-in-original-home' into maint

2015-07-27T19:21:41Z

An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * rh/test-color-avoid-terminfo-in-original-home: test-lib.sh: fix color support when tput needs ~/.terminfo Revert "test-lib.sh: do tests for color support after changing HOME"

Merge branch 'pt/t0302-needs-sanity' into maint

2015-07-15T18:41:21Z

* pt/t0302-needs-sanity: t0302: "unreadable" test needs SANITY prereq

Merge branch 'jc/do-not-feed-tags-to-clear-commit-marks' into maint

2015-07-15T18:41:16Z

"git format-patch --ignore-if-upstream A..B" did not like to be fed tags as boundary commits. * jc/do-not-feed-tags-to-clear-commit-marks: format-patch: do not feed tags to clear_commit_marks()

rev-list: disable --use-bitmap-index when pruning commits

2015-07-01T19:00:50Z

The reachability bitmaps do not have enough information to tell us which commits might have changed path "foo", so the current code produces wrong answers for: git rev-list --use-bitmap-index --count HEAD -- foo (it silently ignores the "foo" limiter). Instead, we should fall back to doing a normal traversal (it is OK to fall back rather than complain, because --use-bitmap-index is a pure optimization, and might not kick in for other reasons, such as there being no bitmaps in the repository). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/stash-require-clean-index' into maint

2015-06-26T06:03:27Z

A hotfix for the topic already in 'master'. * jk/stash-require-clean-index: Revert "stash: require a clean index to apply"

Merge branch 'jk/die-on-bogus-worktree-late' into maint

2015-06-25T18:02:13Z

The setup code used to die when core.bare and core.worktree are set inconsistently, even for commands that do not need working tree. * jk/die-on-bogus-worktree-late: setup_git_directory: delay core.bare/core.worktree errors

Merge branch 'jk/squelch-missing-link-warning-for-unreachable' into maint

2015-06-25T18:02:10Z

Recent "git prune" traverses young unreachable objects to safekeep old objects in the reachability chain from them, which sometimes caused error messages that are unnecessarily alarming. * jk/squelch-missing-link-warning-for-unreachable: suppress errors on missing UNINTERESTING links silence broken link warnings with revs->ignore_missing_links add quieter versions of parse_{tree,commit}

Merge branch 'mm/rebase-i-post-rewrite-exec' into maint

2015-06-25T18:02:09Z

"git rebase -i" fired post-rewrite hook when it shouldn't (namely, when it was told to stop sequencing with 'exec' insn). * mm/rebase-i-post-rewrite-exec: t5407: use <<- to align the expected output rebase -i: fix post-rewrite hook with failed exec command rebase -i: demonstrate incorrect behavior of post-rewrite

test-lib.sh: fix color support when tput needs ~/.terminfo

2015-06-17T22:16:52Z

If tput needs ~/.terminfo for the current $TERM, then tput will succeed before HOME is changed to $TRASH_DIRECTORY (causing color to be set to 't') but fail afterward. One possible way to fix this is to treat HOME like TERM: back up the original value and temporarily restore it before say_color() runs tput. Instead, pre-compute and save the color control sequences before changing either TERM or HOME. Use the saved control sequences in say_color() rather than call tput each time. This avoids the need to back up and restore the TERM and HOME variables, and it avoids the overhead of a subshell and two invocations of tput per call to say_color(). Signed-off-by: Richard Hansen Signed-off-by: Junio C Hamano