Messages in this thread | | | Subject | Re: [PATCH] fread does not return negative on error | From | Junio C Hamano <> | Date | Wed, 24 Jun 2009 09:15:20 -0700 |
| |
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This here script: > > -- snip -- > for file in abspath.c alias.c cache.h color.c color.h config.c ctype.c \ > environment.c exec_cmd.c exec_cmd.h help.c help.h levenshtein.c \ > levenshtein.h pager.c parse-options.c parse-options.h path.c \ > quote.c quote.h run-command.c run-command.h sigchain.c sigchain.h \ > strbuf.c strbuf.h string.c string.h symbol.c symbol.h usage.c \ > util.h wrapper.c > do > echo $file > git shortlog -n -s $file | head -n 2 > done
I have thought about suggesting this myself, and your output for many of the files matched my intuition, but some were grossly off, so I checked.
The above procedure counts commits, and a one liner "s/char \*/const &/" weighs as heavily as the patch that implemented the whole thing, for a file that was done in one commit almost perfectly except that it needed a small constness fix. Summarizing output from "blame" for each file may give you a more meaningful results:
# timestamp ts='[12][0-9][0-9][0-9]-[0-9][0-9]-[0-3][0-9] ..:..:.. [-+]....' # linenum lno='[1-9][0-9]*' git blame "$file" | sed -e 's/^[^ ]* *(\([^)]*[^ ]\) *'"$ts *$lno"').*/\1/' | sort | uniq -c | sort -r -n
For example, I do not think it is fair to credit me for abspath.c more than Dmitry like this:
> outputs this (note that a few files you mentioned are not in git.git): > > abspath.c > 2 Junio C Hamano > 1 Dmitry Potapov
Initially Dmitry introduced this file with 5b8e6f8 (shrink git-shell by avoiding redundant dependencies, 2008-06-28) at 68 lines. J6t added 36 lines for add_path() with 10c4c88 (Allow add_path() to add non-existent directories to the path, 2008-07-21), I added 12 lines to add a new function with 90b4a71 (is_directory(): a generic helper function, 2008-09-09) and then added a two-liner out-of-bounds-then-die check in 737e31a (make_absolute_path(): check bounds when seeing an overlong symlink, 2008-12-17).
| |