threads / discuss / 42276

diff --break-rewrites for just a part of a file

Subject: diff --break-rewrites for just a part of a file

## tl;dr

2 messages between May 10, 2016 and May 10, 2016.

replies: 1people: 2as markdown or json

Sascha Silbe· May 10, 2016, 16:22 UTC · lore

Hello,

the other day I was reviewing a patch that replaced a large chunk in a Makefile with completely different logic. No matter what diff algorithm and options I threw at it, the diff would always synchronise at the empty lines between individual targets and thus show the rewrite of a larger section as complete replacements of many smaller, but directly adjacent sections (only separated by a blank line).

--break-rewrites would be nicely suited for this case, but once I dialed down the parameters enough for the option to apply at all, it showed the entire file as being replaced rather than just the section in between that actually changed. Is there a way to have --break-rewrites leave out the unchanged lines at beginning and end of the file?

A combination of --break-rewrites and --inter-hunk-context that merges changes with less than the given number of unchanged lines between them into a single delete/insert change would be even better. But just ignoring the unchanged header and footer of a file for --break-rewrites would already go a long way.

Sascha

Junio C Hamano· May 10, 2016, 19:16 UTC · re: Sascha Silbe · lore

Re: diff --break-rewrites for just a part of a file

Sascha Silbe <sascha-ml-reply-to-2016-2@silbe.org> writes:

Show 5 quoted lines

> A combination of --break-rewrites and --inter-hunk-context that merges
> changes with less than the given number of unchanged lines between them
> into a single delete/insert change would be even better. But just
> ignoring the unchanged header and footer of a file for --break-rewrites
> would already go a long way.

That's interesting. Break-rewrites as originally designed and implemented is only about "When the entire file been rewritten completely, it is easier to read when the diff did not pay any attention to those accidentally common lines".

We recently had a discussion on tweaking the logic used to merge and minimize hunks; the topic was about where to start the hunk boundary for maximum readability when the beginning and end of a hunk can be shifted around, but this smells like a similar issue.