Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

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

 



Am 11.05.2016 um 00:51 schrieb Junio C Hamano:
The helper function get_func_line() however gets confused when a
hunk adds a new function at the very end, and returns -1 to signal
that it did not find a suitable "function header line", i.e. the
beginning of previous function.  The caller then takes this signal
and shows from the very beginning of the file.  We end up showing
the entire file, starting from the very beginning to the end of the
newly added lines.

We can avoid this by using the original hunk boundary when the
helper gives up.

It's a more conservative fallback in this case, but it regresses e.g. if you have a long list of includes at the top of a C file -- it won't show the full list anymore with -W.

The problem is that we are trying to access lines in the preimage that are only actually in the postimage. Simply switching to useing the postimage unconditionally is not enough -- we'd have the same problem with the complementary case of lines at the end being removed.

I wonder if using the postimage as a fallback suffices. Need to look at this more closely.

René
--
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]