Max Kirillov <max@xxxxxxxxxx> writes: > If `git diff --cc` is used with 2 or more parents, then > it shows all hunks which have changed compared to at least 2 parents. > Which is reasonable, because those places are likely places for > conflicts, and it should be displayed how they were resolved. > But, preliminary path filtering passes a path only it was changed > compared to each parent. So, if a hunk which has not changed compared to > some of parents is shown if there are more changed hunks in the file, > but not shown if it is the only change. > > This looks inconsistent and for some scenarios it is desirable to show > such changes. > > Add the test which demonstrates the issue. > > Signed-off-by: Max Kirillov <max@xxxxxxxxxx> > --- > t/t4059-diff-cc-not-affected-by-path-filtering.sh | 108 ++++++++++++++++++++++ > 1 file changed, 108 insertions(+) > create mode 100755 t/t4059-diff-cc-not-affected-by-path-filtering.sh > > diff --git a/t/t4059-diff-cc-not-affected-by-path-filtering.sh > b/t/t4059-diff-cc-not-affected-by-path-filtering.sh > new file mode 100755 > index 0000000..3e6e59b > --- /dev/null > +++ b/t/t4059-diff-cc-not-affected-by-path-filtering.sh > @@ -0,0 +1,108 @@ ... > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" >long/base && > + git add long/base && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "s/^2/2change1/" >long/win1 && > + git add long/win1 && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "s/^2/2change2/" >long/win2 && > + git add long/win2 && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "s/^2/2merged/" >long/merge && > + git add long/merge && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "/^2/d" >long/delete && > + git add long/delete && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "s/^2/2change1/" >long/only1 && > + git add long/only1 && > + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e > "s/^2/2change2/" >long/only2 && Hmph. Is it gmane who is munging these lines? The other copy of this message I received in my mbox (which I read in the same MUA) does not seem to have this corruption, and I do not expect vger.kernel.org to do this kind of munging without getting yelled at by the kernel folks. Anyway, thanks; I'll take a deeper look once I got a chance to. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html