Re: blame on a deleted/renamed file

On 2009.08.05 10:49:09 -0500, Dan McGee wrote:

2009/8/5 Björn Steinbrink [off-list ref]:

quoted

Hm, I still don't see what you mean. For some lines it stopped at
e19d7da4, yeah, but those were new lines, added in that commit, at least
those that I checked (e.g. "local ct=0" in generate_checksums()). For
the others, it already went back further.

Thought I'd just clarify the lines off-list that I actually cared about:

    # fix flyspray #6246
    local file_type=$(file -bizL "$file")
    local cmd=''
    case "$file_type" in
      *application/x-tar*|*application/zip*|*application/x-zip*|*application/x-cpio*)
        cmd="bsdtar -x -f" ;;
      *application/x-gzip*)
        cmd="gunzip -d -f" ;;
      *application/x-bzip*)
        cmd="bunzip2 -f" ;;
      *application/x-xz*)
        cmd="xz -d -f" ;;
      *)
        # Don't know what to use to extract this file,
        # skip to the next file
        continue;;

Which moved in that commit into a bash function, and I wanted to trace
them back further.

Ah, ok. Most of these got changed later, so the blame is right for them,
but for example the *application/x-gzip*) line was just literally moved
in the file, and blame should be able to follow at least that one. And
it does that as long as you don't cross commit
68c10690eae369928b6cdc2d658588ad06e4b1a5, which changed the cmd="..."
lines. Even with -M5 -C5 -C5 -C5 (which should set the scores low
enough, and enables the hardest following mode) it starts to blame that
line to e19d7da4 then. The same is true if you blame too few lines.

git blame -M5 -C5 -C5 -C5 -w -L/x-gzip/,+3 \
	68c10690eae369928b6cdc2d658588ad06e4b1a5^ -- scripts/makepkg.sh.in

vs.

git blame -M5 -C5 -C5 -C5 -w -L/x-gzip/,+2 \
	68c10690eae369928b6cdc2d658588ad06e4b1a5^ -- scripts/makepkg.sh.in

The first one follows back to 7ed7977e, the other stops at e19d7da4.

I wonder whether that's a plain limitation, or a bug...

Björn