git/builtin/diff.c, branch v2.29.2

diff: get rid of redundant 'dense' argument

2020-09-29T18:54:53Z

Get rid of 'dense' argument that is redundant for every function that has 'struct rev_info *rev' argument as well, as the value of 'dense' passed is always taken from 'rev->dense_combined_merges' field. The only place where this was not the case is in 'submodule.c' where 'diff_tree_combined_merge()' was called with '1' for 'dense' argument. However, at that call the 'revs' instance used is local to the function, and we now just set 'revs->dense_combined_merges' to 1 in this local instance. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

Merge branch 'ct/diff-with-merge-base-clarification' into master

2020-07-09T21:00:43Z

Recent update to "git diff" meant as a code clean-up introduced a bug in its error handling code, which has been corrected. * ct/diff-with-merge-base-clarification: diff: check for merge bases before assigning sym->base

diff: check for merge bases before assigning sym->base

2020-07-08T20:57:18Z

In symdiff_prepare(), we iterate over the set of parsed objects to pick out any symmetric differences, including the left, right, and base elements. We assign the results into pointers in a "struct symdiff", and then complain if we didn't find a base, like so: sym->left = rev->pending.objects[lpos].name; sym->right = rev->pending.objects[rpos].name; sym->base = rev->pending.objects[basepos].name; if (basecount == 0) die(_("%s...%s: no merge base"), sym->left, sym->right); But the least lines are backwards. If basecount is 0, then basepos will be -1, and we will access memory outside of the pending array. This isn't usually that big a deal, since we don't do anything besides a single pointer-sized read before exiting anyway, but it does violate the C standard, and of course memory-checking tools like ASan complain. Let's put the basecount check first. Note that we haveto split it from the other assignments, since the die() relies on sym->left and sym->right having been assigned (this isn't strictly necessary, but is easier to read than dereferencing the pending array again). Reported-by: brian m. carlson Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'dl/diff-usage-comment-update'

2020-06-29T21:17:25Z

An in-code comment in "git diff" has been updated. * dl/diff-usage-comment-update: builtin/diff: fix botched update of usage comment builtin/diff: update usage comment

Merge branch 'ct/diff-with-merge-base-clarification'

2020-06-25T19:27:46Z

"git diff" used to take arguments in random and nonsense range notation, e.g. "git diff A..B C", "git diff A..B C...D", etc., which has been cleaned up. * ct/diff-with-merge-base-clarification: Documentation: usage for diff combined commits git diff: improve range handling t/t3430: avoid undefined git diff behavior

builtin/diff: fix botched update of usage comment

2020-06-23T23:39:41Z

In the previous commit, an attempt was made to correct the "N=1, M=0" case. However, the fix was botched and it introduced two half-correct sections by mistake. Combine these half-correct sections into one fully correct section. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

builtin/diff: update usage comment

2020-06-18T22:01:15Z

A comment in cmd_diff() states that if one tree-ish and no blobs are provided, (the "N=1, M=0" case), it will provide a diff between the tree and the cache. This is incorrect because a diff happens between the tree-ish and the working tree. Remove the `--cached` in the comment so that the correct behavior is shown. Add a new section describing the "N=1, M=0, --cached" behavior. Next, describe the "N=0, M=0, --cached" case, similar to the above since it is undocumented. Finally, fix some spacing issues. Add spaces between each section for consistency and readability. Also, change tabs within the comment into spaces. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Documentation: usage for diff combined commits

2020-06-12T17:53:44Z

Document the usage for producing combined commits with "git diff". This includes updating the synopsis section. While here, add the three-dot notation to the synopsis. Make "git diff -h" print the same usage summary as the manual page synopsis, minus the "A..B" form, which is now discouraged. Signed-off-by: Chris Torek Signed-off-by: Junio C Hamano

git diff: improve range handling

2020-06-12T17:53:44Z

When git diff is given a symmetric difference A...B, it chooses some merge base from the two specified commits (as documented). This fails, however, if there is *no* merge base: instead, you see the differences between A and B, which is certainly not what is expected. Moreover, if additional revisions are specified on the command line ("git diff A...B C"), the results get a bit weird: * If there is a symmetric difference merge base, this is used as the left side of the diff. The last final ref is used as the right side. * If there is no merge base, the symmetric status is completely lost. We will produce a combined diff instead. Similar weirdness occurs if you use, e.g., "git diff C A...B D". Likewise, using multiple two-dot ranges, or tossing extra revision specifiers into the command line with two-dot ranges, or mixing two and three dot ranges, all produce nonsense. To avoid all this, add a routine to catch the range cases and verify that that the arguments make sense. As a side effect, produce a warning showing *which* merge base is being used when there are multiple choices; die if there is no merge base. Signed-off-by: Chris Torek Signed-off-by: Junio C Hamano

oid_array: rename source file from sha1-array

2020-03-30T17:59:08Z

We renamed the actual data structure in 910650d2f8 (Rename sha1_array to oid_array, 2017-03-31), but the file is still called sha1-array. Besides being slightly confusing, it makes it more annoying to grep for leftover occurrences of "sha1" in various files, because the header is included in so many places. Let's complete the transition by renaming the source and header files (and fixing up a few comment references). I kept the "-" in the name, as that seems to be our style; cf. fc1395f4a4 (sha1_file.c: rename to use dash in file name, 2018-04-10). We also have oidmap.h and oidset.h without any punctuation, but those are "struct oidmap" and "struct oidset" in the code. We _could_ make this "oidarray" to match, but somehow it looks uglier to me because of the length of "array" (plus it would be a very invasive patch for little gain). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano