Junio C Hamano writes:
> I do not think you should step outside diff_flush(). Only when
> producing textual diff, you would have to run the textual diff
> twice by going over the q twice:
>
> * The first pass would run diff_flush_patch(), which would call
>into xdiff the
On Fri, Sep 2, 2016 at 8:31 PM, Stefan Beller wrote:
> When moving code (e.g. a function is moved to another part of the file or
> to a different file), the review process is different than reviewing new
> code. When reviewing moved code we are only interested in the diff as
>
On Sat, Sep 3, 2016 at 11:41 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> * On 2/2, doing it at xdiff.c level may be limiting this good idea
>>>to flourish to its full potential, as the interface is fed only
>>>one diff_filepair at a
Stefan Beller writes:
>> * On 2/2, doing it at xdiff.c level may be limiting this good idea
>>to flourish to its full potential, as the interface is fed only
>>one diff_filepair at a time.
>
> I realized that after I implemented it. I agree we would want to have
> it
On Sat, Sep 3, 2016 at 12:00 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> A line is colored differently if that line and the surroundign 2 lines
>> appear as-is in the opposite part of the diff.
>>
>> Example:
>> http://i.imgur.com/ay84q0q.png
>>
Stefan Beller writes:
> A line is colored differently if that line and the surroundign 2 lines
> appear as-is in the opposite part of the diff.
>
> Example:
> http://i.imgur.com/ay84q0q.png
>
> Or apply these patches and
> git show
When moving code (e.g. a function is moved to another part of the file or
to a different file), the review process is different than reviewing new
code. When reviewing moved code we are only interested in the diff as
where there are differences in the moved code, e.g. namespace changes.
However
7 matches
Mail list logo