Hi Andrei, Thanks for the prompt reply. I'm sorry for the false alarm, I should've investigated this more thoroughly before submitting a bug. Now I see I get that context hint in many diffs, I was confused by many simple file diffs I was working with recently which didn't have it. Thank you for your time and help. Kind regards, Daniil Penkin вс, 24 июн. 2018 г. в 23:33, Andrei Rybak <rybak.a.v@xxxxxxxxx>: > > On 2018-06-24 12:36, Daniel Penkin wrote: > > Hello, > > > > Hi, > > > I believe I found a bug in how Git represents a diff when invoked with > > "--find-copies-harder" parameter. > > Specifically, the unified diff header of a hunk contains an extra > > piece of text which appears to be a line from the context (i.e. > > unchanged line), something like this: > > > > > git diff --find-copies-harder d00ca3f 20fb313 > > diff --git a/test.txt b/copy.txt > > similarity index 81% > > copy from test.txt > > copy to copy.txt > > index 734156d..43a3f9d 100644 > > --- a/test.txt > > +++ b/copy.txt > > @@ -2,6 +2,7 @@ line 1 > > line 2 > > line 3 > > line 4 > > +added line > > line 5 > > line 6 > > line 7 > > > > Note "line 1" after the standard unified diff header. > > > > This text after @@ is usually a function name in a programming language or > some other relevant part of hunk context, to help user navigate the diff more > easily. What you are getting is the default version of it, as it is just > comparing txt files. You can read more about it in the documentation of > gitattributes: > > https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header > > > I prepared a sample repository with a minimal file I can reproduce > > this problem with: > > https://bitbucket.org/dpenkin/find-copies-harder-bug > > > > I'm running Git 2.18.0 on a macOS, but I also tried with Git 2.15.0 > > and 2.8.6 running on Alpine Linux and was able to reproduce the same > > problem. > > > > Please advise whether this is expected output or is indeed a bug. > > > > This is expected output. > > > Thank you. > > > > Kind regards, > > Daniil Penkin > > > > -- > Best regards, Andrei R.