Re: a problem with git diff

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

 



On 2020-04-16 at 16:43:40, Guy Maurel wrote:
> Hello!
> 
> Using the appended two files:
>   git diff combine.cpp-2020-04-16-A combine.cpp-2020-04-16-R > git-diff.diff-Y
> 
> doesn't show the same differences as with:
>   meld combine.cpp-2020-04-16-R combine.cpp-2020-04-16-A
> 
> Have a look at git-diff.diff-Y at line 210:
> -static void process_returns(void)
> +static void mark_lvalue(chunk_t *pc)
> 
> which is NOT correct.

It looks like there's some additional code that gets inserted before the
process_returns function.  In this case, the diff is accurate in that
applying it to the old file will result in the new file, but it's not
very helpful.

The reason is that the default diff algorithm, myers, looks for common
lines and finds them in the blank lines in both process_returns and the
new code above it.  It then writes the diff as a set of deletions of the
lines in process_returns and an addition of the lines in the new code,
plus a final addition of the process_returns function.  While correct,
this is, as you noted, confusing.

If you're looking for a more helpful output, you can use
--diff-algorithm=patience (or diff.algorithm=patience), which results
in a diff output that more logically matches what most humans would like
to see.  You can also use the histogram diff algorithm, which is based
on patience but has some additional heuristics.  Which one produces
better output differs depending on the circumstance.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature


[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