Junio C Hamano wrote: > I think what makes this paragraph unnecessarily hard to read is the > "While rename works". > > With that, you are implying "if you rename a file as a whole without > changing the block of text you identify with the -S parameter, then > such a change is not interesting as far as pickaxe is concerned". > while that statement is logically correct, normal people are not > that generous to read that much between your lines. Yes, I'm exactly implying that. But I don't want to lose meaning: in the previous sentence, I talk about filepairs. I want to point out that rename detection working at the filepair level is a perfectly normal thing. > I think that is one of the reasons why "If you moved a string from > file A to file B, log -S will flag that change as worth inspecting" > does not seem to logically follow and made Phil find your > description confusing. Sure, we can elaborate a bit more. > Finding such a change indeed is a feature [*1*]; we need to flag > such a change as worth inspecting to find where the code came from > in order to dig deeper, so at least this "cannot omit" should be > "does not omit". What I was trying to say is that it's an accidental feature: the reason this "feature" exists is because diffcore is tied to filepairs (and rename detection works at the filepair level). You may argue that there's nothing wrong with this design, but consider what happens if you rebase on top of a big code move: it's completely broken. If git were a true content tracker, and file boundaries really did not matter, isn't this feature actually a deficiency? Ofcourse, the user doesn't need to know all this, and "does not omit" is a good suggestion. -- 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