Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > I thought there was a way to use git-blame to find out whether a change > only shuffled lines, but otherwise did not modify them. I tried "git blame > -M -- the/file",... You said "a change" and I somehow expected that such a blame would be done with a revision range, e.g. "git blame -M HEAD^..HEAD -- the/file". If the two endpoints you are comparing have other commits in between that make changes then revert them in such a way that the end result cancels out, "git diff A B -- the/file" won't see such intermediate changes, but they may interfere with "git blame A..B -- the/file", i.e. when A is not a direct parent of B. > ... nor with a 5000+ lines file (with 55 lines moved). > ... while this produces the same as with just -M: > $ git blame -M2 -s -- foo Yes, blame tries to omit matches that consists only of non words, so that you won't see "all those lines with a single "}" on them that close definitions for your 100 new functions were copied from the closing brace of one function you originally had in the file" symptom, and -M<level> controls it. > But neither helps with my 5000+ lines file. Does it mean that the lines > were changed? But I'm sure they were just moved! Please help! When reviewing a "supposedly move-only" change, I typically just grab +/- blocks from the patch, remove the +/- prefix and run comparison between them. -- 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