Re: Incorrect unified diff when run with "--find-copies-harder"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux