On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > Could you cut down to a real minimal reproduction, i.e. just these 20
> > lines or so?
>
> I'm working on getting down to a minimal reproduction, a few lines at
> a time. One thing that seems strange: as I've removed lines, there are
> a bunch of lines that don't matter. Then I'll find some lines that, if
> removed, completely fix the issue. But the ordering for these
> apparently important lines doesn't matter. They just have to be
> somewhere in the file to cause the duplicated diffs.
>
> I'll upload again when I've figured out all the unimportant lines to remove.
Yeah, I reproduced based on your initial post, but noticed that when I
cut it down the problem went away.
An easy and pretty mechanical reproduction is:
git diff --no-index unitera_bold_italic.bdf.{old,new} |
sed -ne '/STARTCHAR U+00F0/,/ENDCHAR/p'
which shows a hunk that could easily be reduced by its first line
("DWIDTH 8 0"), and which has a common line in the middle of -/+ run.
But if we cut it down to the lines in that hunk, like this:
for i in unitera_bold_italic.bdf.{old,new}; do
sed -ne '/STARTCHAR U+00F0/,/ENDCHAR/p' <$i >$i.cut
done
git diff --no-index unitera_bold_italic.bdf.{old,new}.cut
then those two lines become context.
I note also that GNU "diff -u" gets this case right.
> > Do you have any smudge filters or configuration regarding
> > line endings?
>
> No filters, I did have core.autocrlf = input. But as I mentioned, I
> can also reproduce with an empty config.
Me too. Amusingly, if you have diff.colorMoved configured, the context
lines appear as moves, showing that we really do know they're the same
(but that happens as post-diff processing, so I am not at all surprised
that it is orthogonal to the original issue).
-Peff
