Originally Posted By: canuckInOR
Originally Posted By: tfabris
So Git is just PLAIN OLD STUPID with regard to this then?
Yeah, and a patch doesn't look trivial, either. From a cursory look at the source, it may be leaning on the xdiff library for this functionality.

This is more interesting than my real work, so...

I was wrong about it leaning on xdiff -- at least for my test. But it is indeed a non-trivial patch.

The three functions in question are all in line-range.c: match_funcname, find_funcname_matching_regexp, and parse_range_funcname.

We start out in parse_range_funcname, and move through the lines of code until we find a regex match for the function name by calling find_funcname_matching_regexp. That finds the start of the line, and then calls match_funcname. All that does is check that the line starts with an alpha, underscore, or $ character. Then we start looking for the next line that starts with an alpha, underscore, or $ character -- the next line that we find that matches is the end of the range.

So not only does this code fail to work for indented code, it fails to work for non-indented code, as well. The problem is that git, since it doesn't know the language, can't distinguish between the function being called in the code, and the definition of the function.

Lets assume we implement a patch to skip leading indent, and match the indent level. What if the code looks like this:
Code:
class foo {
    int some_other_func() {
        // ...
        if (funcname()) {
            // ...
        }
        return 0;
    }

    int funcname() {
        // ...
    }
};


So now we say "aha, I found funcname, and it has a leading indent of 8 spaces," and the resulting range will give you:
Code:
        if (funcname()) {
            // ...
        }


Clearly not what we want, either. So git is using the notion that a function signature must start at the beginning of the line, or it's not the function, but a function call. And I can't think of any other reliable alternative

So... ultimately, if you want something better than git's rudimentary assumption, you need to actually parse the language itself -- and that's clearly not git's job.