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
while this produces the same as with just -M:
$ git blame -M2 -s -- foo
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!
-- Hannes
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
Am 10/19/2011 18:33, schrieb Jeff King:
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).
I see. My example is more like this:
for i in `seq 1 20`; do md5sum - <<< $i; done > foo
git commit -a -m foo
for i in `seq 1 20`; do md5sum - <<< $i; done | sort > foo
git commit -a -m foo\ sorted
i.e., the sort order of a block of lines was changed "in place". Here,
most of the lines are attributed to the last commit. Am I expecting too
much from git-blame to detect line motions in such a case?
-- Hannes