Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> Lines of code and file sizes: file size needs additional invocation >> per each file for gitweb; it would be easier for cgit. Costly! >> Counting LOC is even more costly: take note that 1.) gitweb operates >> directly on repository / object database, and does not use working >> area, 2.) git is snapshot based and not changeset based. > > We earlier discussed to make --numstat to allow us add this kind > of information for easier script consumption. > > Perhaps instead of modifying --numstat, we may be better off to > add another format that can be more easily extended to support > other things, like we do for the --porcelain format out of > git-blame? It does not have to be one line per record, like the > way --numstat was done, which was primarily in order to make it > a compact, human readable format. Even if we extend --numstat or add yet another diff format meant for porcelain[*1*], and optionally add similar extension to git-ls-tree (as I think object size and LOC of file should be placed there), and the cost of additional fork and exec is not an issue, such extra information be still costly in terms of performance: CPU and I/O. Currently for difftree (whatchanged-like) we need only to compare trees. For lines added / lines removed statistics we need to _generate_ diff. For file size (object size) we need at least find the object in question and read it's header; for lines of code we need to get blob contents (find object, uncompress, optionally undeltify) and count the lines. Its not insurmountable: we can use %feature for that, like in the case of other CPU-intensive features like 'blame' or 'pickaxe', or high-bandwidth features like 'snapshot'. Footnotes: ---------- [*1*] What we should name it? --numstat-extended, --machinestat, --porcelain, --allstat, <insert your own idea here>? -- Jakub Narebski Poland - 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
