git/combine-diff.c, branch v2.4.9

diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT

2015-05-27T20:54:42Z

The latter is a much more descriptive name (and we support "color.diff.context" now). This also updates the name of any local variables which were used to store the color. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/pretty-empty-format'

2014-09-02T20:25:04Z

"git log --pretty/format=" with an empty format string did not mean the more obvious "No output whatsoever" but "Use default format", which was counterintuitive. * jk/pretty-empty-format: pretty: make empty userformats truly empty pretty: treat "--format=" as an empty userformat revision: drop useless string offset when parsing "--pretty"

Merge branch 'jk/diff-tree-t-fix'

2014-08-26T18:16:26Z

Fix (rarely used) "git diff-tree -t" regression in 2.0. * jk/diff-tree-t-fix: intersect_paths: respect mode in git's tree-sort

intersect_paths: respect mode in git's tree-sort

2014-08-20T20:38:37Z

When we do a combined diff, we individually diff against each parent, and then use intersect_paths to do a parallel walk through the sorted results and come up with a final list of interesting paths. The sort order here is that returned by the diffs, which means it is in git's tree-order which sorts sub-trees as if their paths have "/" at the end. When we do our parallel walk, we need to use a comparison function which provides the same order. Since 8518ff8 (combine-diff: optimize combine_diff_path sets intersection, 2014-01-20), we use a simple strcmp to compare the pathnames, and get this wrong. It's somewhat hard to trigger because normally a diff does not produce tree entries at all, and therefore the sort order is the same as a strcmp. However, if the "-t" option is used with the diff, then we will produce diff_filepairs for both trees and files. We can use base_name_compare to do the comparison, just as the tree-diff code does. Even though what we have are not technically base names (they are full paths within the tree), the end result is the same (we do not care about interior slashes at all, only about the final character). However, since we do not have the length of each path stored, we take a slight shortcut: if neither of the entries is a sub-tree then the comparison is equivalent to a strcmp. This lets us skip the extra strlen calls in the common case without having to reimplement base_name_compare from scratch. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pretty: make empty userformats truly empty

2014-07-30T19:30:08Z

If the user provides an empty format with "--format=", we end up putting in extra whitespace that the user cannot prevent. This comes from two places: 1. If the format is missing a terminating newline, we add one automatically. This makes sense for --format=%h, but not for a truly empty format. 2. We add an extra newline between the pretty-printed format and a diff or diffstat. If the format is empty, there's no point in doing so if there's nothing to separate. With this patch, one can get a diff with no other cruft out of "diff-tree --format= $commit". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'mk/show-s-no-extra-blank-line-for-merges'

2014-06-06T18:35:02Z

* mk/show-s-no-extra-blank-line-for-merges: git-show: fix 'git show -s' to not add extra terminator after merge commit

git-show: fix 'git show -s' to not add extra terminator after merge commit

2014-05-15T16:32:08Z

When git show -s is called for merge commit it prints extra newline after any merge commit. This differs from output for commits with one parent. Fix it by more thorough checking that diff output is disabled. The code in question exists since commit 3969cf7db1. The additional newline is really needed for cases when patch is requested, test t4013-diff-various.sh contains cases which can demonstrate behavior when the condition is restricted further. Tests: Added merge commit to 'set up a bit of history' case in t7007-show.sh to cover the fix. Existing tests are updated to demonstrate the new behaviour. Earlier, the tests that used "git show -s --pretty=format:%s", even though "--pretty=format:%s" calls for item separator semantics and does not ask for the terminating newline after the last item, expected the output to end with such a newline. They were relying on the buggy behaviour. Use of "--format=%s", which is equivalent to "--pretty=tformat:%s" that asks for a terminating newline after each item, is a more realistic way to use the command. In the test 'merge log messages' the expected data is changed, because it was explicitly listing the extra newline. Also the msg.nologff and msg.nolognoff expected files are replaced by one msg.nolog, because they were diffing because of the bug, and now there should be no difference. Signed-off-by: Max Kirillov Signed-off-by: Junio C Hamano

combine-diff: speed it up, by using multiparent diff tree-walker directly

2014-04-07T21:41:49Z

As was recently shown in "combine-diff: optimize combine_diff_path sets intersection", combine-diff runs very slowly. In that commit we optimized paths sets intersection, but that accounted only for ~ 25% of the slowness, and as my tracing showed, for linux.git v3.10..v3.11, for merges a lot of time is spent computing diff(commit,commit^2) just to only then intersect that huge diff to almost small set of files from diff(commit,commit^1). In previous commit, we described the problem in more details, and reworked the diff tree-walker to be general one - i.e. to work in multiple parent case too. Now is the time to take advantage of it for finding paths for combine diff. The implementation is straightforward - if we know, we can get generated diff paths directly, and at present that means no diff filtering or rename/copy detection was requested(*), we can call multiparent tree-walker directly and get ready paths. (*) because e.g. at present, all diffcore transformations work on diff_filepair queues, but in the future, that limitation can be lifted, if filters would operate directly on combine_diff_paths. Timings for `git log --raw --no-abbrev --no-renames` without `-c` ("git log") and with `-c` ("git log -c") and with `-c --merges` ("git log -c --merges") before and after the patch are as follows: linux.git v3.10..v3.11 log log -c log -c --merges before 1.9s 16.4s 15.2s after 1.9s 2.4s 1.1s The result stayed the same. Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano

combine-diff: move changed-paths scanning logic into its own function

2014-02-24T22:46:11Z

Move code for finding paths for which diff(commit,parent_i) is not-empty for all parents to separate function - at present we have generic (and slow) code for this job, which translates 1 n-parent problem to n 1-parent problems and then intersect results, and will be adding another limited, but faster, paths scanning implementation in the next patch. Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano

combine-diff: move show_log_first logic/action out of paths scanning

2014-02-24T22:46:11Z

Judging from sample outputs and tests nothing changes in diff -c output, and this change will help later patches, when we'll be refactoring paths scanning into its own function with several variants - the show_log_first logic / code will stay common to all of them. NOTE: only now we have to take care to explicitly not show anything if parents array is empty, as in fact there are some clients in Git code, which calls diff_tree_combined() in such a way. Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano