Re: suggestions for gitweb

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: suggestions for gitweb

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:10

Jakub Narebski [off-list ref] 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.

Re: suggestions for gitweb

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:43:10

Junio C Hamano wrote:
Jakub Narebski [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help