> If "--show-c-function" output is the problem, perhaps we should know a bit > better about what C function header looks like? In fact the "--show-c-function" output is the problem. But I think that a change can't be rejected because of another issue. The style of placing "goto"-statements, which leave a function to the end of that is used in many other projects. And I think it's very usefull. 2010/12/1 Jonathan Nieder <jrnieder@xxxxxxxxx>: > Junio C Hamano wrote: >> Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >>> A space before the "bad_graft_data:" label would improve future >>> diff --show-c-function output. >> >> Hmm, I actually do not think we encourage that (nor we should). >> >> Â Â $ git grep -e '^ [a-z0-9]*:' -- '*.c' | wc -l >> Â Â 23 >> Â Â $ git grep -e '^[a-z0-9]*:' -- '*.c' | wc -l >> Â Â 42 >> >> If "--show-c-function" output is the problem, perhaps we should know a bit >> better about what C function header looks like? > > Thanks for checking. ÂYes, I think so. > > Â Â Â Â$ git grep --show-function strbuf_release -- http.c > Â Â Â Âhttp.c=static int http_request(const char *url, void *result, int target, int options) > Â Â Â Âhttp.c: strbuf_release(&buf); > Â Â Â Âhttp.c=cleanup: > Â Â Â Âhttp.c: strbuf_release(&tmpfile); > Â Â Â Âhttp.c=int http_fetch_ref(const char *base, struct ref *ref) > Â Â Â Âhttp.c: strbuf_release(&buffer); > > The following gives me some joy. > > Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > --- > diff --git a/.gitattributes b/.gitattributes > index 5e98806..5888a53 100644 > --- a/.gitattributes > +++ b/.gitattributes > @@ -1,3 +1,4 @@ > Â* whitespace=!indent,trail,space > Â*.[ch] whitespace=indent,trail,space > +*.[ch] diff=cpp > Â*.sh whitespace=indent,trail,space > -- 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