Re: weird diff output?

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

 



On Mon, Mar 28, 2016 at 5:26 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote:
> On Mon, Mar 28, 2016 at 4:28 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
>>  cat > expect <<EOF
>> +Entering '../nested1'
>> +Entering '../nested1/nested2'
>> +Entering '../nested1/nested2/nested3'
>> +Entering '../nested1/nested2/nested3/submodule'
>> +Entering '../sub1'
>> +Entering '../sub2'
>> +Entering '../sub3'
>> +EOF
>> +
>> +test_expect_failure 'test messages from "foreach --recursive" from subdirectory' '
>> +       (
>> +               cd clone2 &&
>> +               mkdir untracked &&
>> +               cd untracked &&
>> +               git submodule foreach --recursive >../../actual
>> +       ) &&
>> +       test_i18ncmp expect actual
>> +'
>> +
>> +cat > expect <<EOF
>>  nested1-nested1
>>  nested2-nested2
>>  nested3-nested3
>
> Complete tangent here. The diff above looks like
>
> <old-line>
> +
> +
> +
> +
> +<old-line>
>
> is it possible to get diff output that would look more like
>
> +<old-line>
> +
> +
> +
> +
> +
> <old-line>
>
> instead? This is one of those huge readability issues with diff
> formatting that seems like both are completely correct, but the second
> way is much easier in general to read what was added.
>
> I don't understand why diff algorithms result in the former instead of
> the latter, and am curious if anyone knows whether this has ever been
> thought about or solved by someone.

I thought this is an optimization for C code where you have a diff like:

    int existingStuff1(..) {
    ...
    }
    +
    + int foo(..) {
    +...
    +}

    int existingStuff2(...) {
    ...

Note that the closing '}' could be taken from the method existingStuff1 instead
of correctly closing foo. So the correct heuristic really depends on
what kind of text
we are diffing.

Maybe we need the opposite of the 'patience' algorithm in format-patch?

Another heuristic would be to check for empty lines and use that as a
strong hint,
whether to use the first or last line. (Rule: Try to use that last or
first line such that
the lines at the edges of the diff are empty lines, it needs to be
formalized a bit more)

>
> I've tried using various diffing algorithms (histogram, etc) and they
> always produce the same result above, and never what I would prefer.
>
> Regards,
> Jake

Thanks,
Stefan
--
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



[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]