On Tue, Jun 27, 2017 at 8:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> It is useful to have moved lines colored, but there are annoying corner >> cases, such as a single line moved, that is very common. For example >> in a typical patch of C code, we have closing braces that end statement >> blocks or functions. >> >> While it is technically true that these lines are moved as they show up >> elsewhere, it is harmful for the review as the reviewers attention is >> drawn to such a minor side annoyance. >> >> One of the first solutions considered, started off by these hypothesis': > > Hypotheses is the plural form of that word, I think. > >> (a) The more blocks of the same code we have, the less interesting it is. >> (b) The shorter a block of moved code is the less need of markup there >> is for review. >> >> Introduce a heuristic which drops any potential moved blocks if their >> length is shorter than the number of potential moved blocks. >> >> This heuristic was chosen as it is agnostic of the content (in other >> languages or contents to manage, we may have longer lines, e.g. in >> shell the closing of a condition is already 2 characters. Thinking >> about Latex documents tracked in Git, there can also be some >> boilerplate code with lots of characters) while taking both >> hypothesis' into account. An alternative considered was the number >> of non-whitespace characters in a line for example. > > It was puzzling what the above two paragraphs were. I took (a) and > (b) were the hypotheses, and the two above, and also the next > paragraphs, were the design that fell out of them. But that is not > what is happening. You changed your mind and settled on the design > in the next paragraph. Yes, I somehow want to say: "What is implemented in this patch is stupid. And I know it, but I know no smarter idea. This is what I thought was smarter, maybe someone in the future can be inspired by this, at least." > Perhaps we can do without all of the "I thought about this but it > didn't make sense" that is longer than the solution in the patch? As I do changes based on your responses, I want to squash these patches sent out last night into the original patch, so I'll butcher the commit message to be way smaller
