On Wed, Oct 19, 2011 at 04:34:20PM +0200, Johannes Sixt wrote: > 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", but it does not work as expected, neither with a toy file > nor with a 5000+ lines file (with 55 lines moved). > > git init > echo A > foo > echo B >> foo > git add foo > git commit -m initial > echo B > foo > echo A >> foo > git commit -a -m swapped > > The results are: > $ git blame -M -s -- foo > ^e3abca2 1) B > 6189cb46 2) A > > I would have expected: > ^e3abca2 1) B > ^e3abca2 2) A > > Oh, look! This produces the expected result: > $ git blame -M1 -s -- foo Right. Your toy lines aren't long enough to be considered "interesting" by the default score. From git-blame(1): -M[<num>] [...] <num> is optional but it is the lower bound on the number of alphanumeric characters that git must detect as moving/copying within a file for it to associate those lines with the parent commit. The default value is 20. Whereas with a longer sample: git init seq 1 5000 >foo git add foo git commit -m initial sed -i '/^2..$/d' foo seq 200 299 >>foo git commit -a -m 'move 200-299 to end' I get the expected result from "git blame -M" (i.e., everything attributed to the root commit). > 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! What does the file look like? I think blame has some heuristics about lines which are uninteresting, and maybe you are triggering a corner case there. -Peff -- 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