Re: Lines missing from git diff-tree -p -c output?

Hi Junio,

I think the differences is mostly in the locality of the fix. In my proposed patch, the no_pre_delete flag is never set on an interesting line because it is checked in the line before it. In your patch, it never happens because the control flow guarantees the "context" lines before each change must be uninteresting.

The net effect is of course identical, but I'm arguing that depending on the control flow and some code a doze lines down is easier to break than depending on a previous line.

Having said that: I'm not sure if the difference is significant enough to convince me in either direction.

However, thinking about this a bit more (and getting sidetracked on a completely separate issue/question), I wonder why the coalescing-hunks code is there in the first place? e.g., why not leave out these lines?

	if (k < j + context) {
		/* k is interesting and [j,k) are not, but
		 * paint them interesting because the gap is small.
		 */
		while (j < k)
			sline[j++].flag |= mark;
		i = k;
		goto again;
	}

If the "context" lines before and after each group of changes are painted interesting, then these lines in between will also be painted interesting. Of course, this could cause some lines to be painted as interesting twice and it needs my fix for the no_pre_delete thing, but it would work just as well?

However, I can imagine that this code is present to prevent painting lines twice, which would of course be a bit of a performance loss. But if this really was the motivation, why is the first if not something like:

	if (k <= j + 2 * context) {

Since IIUC, the current code can still paint a few context lines twice when they are exacly "context" lines apart, once by the "paint before" and one by the "paint after" code (which is also what happens in my bug example, I think). The above should "fix" that as well (the first part of the test suite hasn't complained so far).

Gr.

Matthijs