{"thread":{"id":"5862","subject":"[RFC] gitweb wishlist and TODO list","startedAt":"2006-10-09T12:49:03Z","lastAt":"2006-10-15T15:17:18Z","messageCount":8,"participants":["Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28454","messageId":"egdge3$t12$1@sea.gmane.org","threadId":"5862","inReplyTo":null,"subject":"[RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-09T12:49:03Z","receivedAt":"2006-10-09T12:49:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"There is a new part of gitweb TODO list and wishlist; planned features and\nfeatures it would be nice to have. If you have new ideas, if you want some\nfeatures to be implemented first, if you use some web interface to some SCM\nyou like, please do contribute.\n\nI've tried to divide this TODO/wishlist into categories.\n\n\n1. Cleanups and refactoring\n\n * HTML and CSS cleanup. All (or almost all) styling should be done using\n   CSS, and not embedded style or presentation elements. All HTML elements\n   except perhaps a few should have either class attribute (if such\n   element can be multiple times on page) or id attribute (if there can be\n   only one such element). Perhaps some class attributes should be changed\n   to id attributes. Gitweb has much improved from the incorporation in\n   this area.\n\n * CSS refactoring. Try to avoid repeating the same styling, using\n   combination of descendant and _child_ selectors, perhaps also\n   adjacent sibling selector and attribute/attribute value selector.\n   Perhaps large reorganization patch (moving contents within CSS and adding\n   comments) is to be done...\n\n * Code refactoring. Separate/refactor common parts and put them into\n   separate subrotines OR collapse similar subrotines into one subroutine\n   with an argument selecting the case. For example git_blob and\n   git_blob_plain could be collapsed; git_shortlog, git_tags/git_heads,\n   git_log, git_history do similar work. When the new\n   --grep/--author/--commiter options to git-rev-list hits released version,\n   perhaps also git_search could be put together with the previous set.\n   git_rss does similar work as a git_summary.\n\n * Refactor printing related links (like \"blame | history | raw\" for blob\n   entries in tree view) into separate subroutine. The list depends both on\n   the kind of object pointed, and on the current action/view.\n\n * Perhaps refactor reading and validation of parameters, except the ones\n   used for dispatch i.e. project and action parameters, into separate\n   subroutine\n \n        my ($hash, $hash_base) = gitweb_params('hash', 'hash_base');    \n\n   I'm not sure if it is/would be usefull.\n\n\n2. Git.pm-ish (subroutines which in generalized version are/could be\n   in Git.pm)\n \n * Refactor calling a git command and reading it's output into separate\n   subroutine git_command/git_pipe, so for example if someone _has_ to use\n   gitweb with ancient Perl version which does not understand list version\n   of magic \"-|\" open could do it changing only one subroutine. Well, we can\n   use Git.pm when it hits main release.\n\n * Add subroutine/subroutines, which given a full name of ref, returns\n   either another ref if input ref was symlink/symref, or hash of the\n   pointed object, and which work not only with ordinary loose refs, but\n   also with symlinks, symrefs (up to some level of recursion) and packed\n   refs. All without calling any git command. But I guess that currently\n   it is not needed at all.\n\n * Add simplified git config file parser, which would _read_ only gitweb\n   entries (and convert them to bool/int if necessary). With this we could\n   move description, category, export_ok, .hide, cloneurl to config file,\n   instead of cluttering $GIT_DIR. Or just make it an option (read file\n   first, if it doesn't exist try config file).\n\n * Parsing of remotes/ files _and_ equivalent config entries, for adding\n   information (tooltip?) about tracking branches in heads view, and for\n   adding information about given subdirectory in refs/remotes/ (see below).\n\n\n3. Optimizing gitweb\n\n * Use git-for-each-ref (when it hits released version) to speed up of\n   generation of summary, heads and tags views. It would also enable the\n   option of having most recent commit date in projects list view, and not\n   most recent commit in current branch (in HEAD).\n \n * Add better support for mod_perl, e.g. $r->path_info(), via checking for\n   MOD_PERL enviromental variable.\n\n * Better support for mod_perl/FastCGI, perhaps wrapping the changeable part\n   into gitweb_handler subroutine, and calling it.\n\n\n4. New features\n\n * Add support for other directories in $refs/ besides \"heads\" and\n   \"tags\" directories, for example refs/remotes/ generated when cloning with\n   --use-separate-remote option. On short TODO list.\n\n * Add categories support a la gitweb-xmms2 to the projects list view (and\n   perhaps also OPML); perhaps with option to use first part of path to\n   repository as category.\n\n * Code highlighting (or generic filter) support in blob view, perhaps as\n   a feature. Proposed tools for generating syntax highlighting include\n   Highlight (http://www.andre-simon.de) and GNU Source Highlight\n   (http://www.gnu.org/software/src-highlite) a la gitweb-xmms2.\n   Gitweb-xmms2 uses Highlight, and due to the tags support uses temporary\n   files. I think that CSS for code highlighting should be in separate file,\n   and that selecting syntax to use should be done using mime.types like\n   file rather than gitweb-xmms2 internal configuration (hash of\n   extensions).\n\n * Committags support from gitweb-xmms2 in commit, commitdiff, log views and\n   in the top commit summary/title link on most pages. There was preliminary\n   patch on git mailing list for committags support (more general than\n   the support in gitweb-xmms2), with current commitsha link (now in\n   format_log_line_html) implemented as committag. Junio had quite\n   a good idea how to avoid having to do committags _after_ HTML escaping,\n   and how to stack committags. I'm not sure if it wouldn't be better to try\n   to do all committags in one go, instead of stacking. Perhaps also commit\n   message \"syntax highlighting\" (i.e. highlighting signoff lines) and empty\n   lines simplification should be done using committags.\n\n * Crossreferencing in blob view. Gitweb-xmms2 uses if I remember correctly\n   etags to generate anchors and to generate hyperlinks to definition of\n   function. GNU Highlight can use encumberant-tags IIRC. Both need I think\n   temporary files for index. Perhaps this should be done rather as a part\n   of gitweb/git integration with LXR Cross Referencer. \n\n   Do you know other projects that could be used instead of etags here?\n\n   I'm not sure if it is worth to pursue implementing it now.\n\n * Improve blame view, making use of --porcelain option to git-blame (for\n   later). Perhaps change blame view from table based one to div based one.\n   Use different colors for different commits (graph coloring problem).\n\n * Perhaps add some kind of finding closest preceding/following tag. and on\n   which branch we are on. Tempered of course by the concerns of\n   performance. What is possible for locally run history browser like gitk\n   or qgit, might be not feasible on server run web interface.\n\n * Add information from remotes/ to heads view, for example the following\n     tracks branch 'master' of git://git.kernel.org/pub/scm/git/git (origin)\n   as a tooltip for 'origin' branch. But what if one branch tracks more than\n   one remote? Needs to use also config file.\n\n * Support for tracking renames in history view. Simple rename tracking\n   I think could be done directly in gitweb; more advanced would need\n   --follow option (i.e. core git improvement).\n\n * log/shortlog should be a format, so we could have log-like history, tags,\n   heads views.\n\n * add summary of number of lines changed for each file (a la darcsview)\n   in the difftree part of commit and *diff* views, e.g.\n\n        blame.c   +1 -0  diff | history | blame\n\n   or something like that.\n\n * add extended header to the commitdiff and perhaps blobdiff views,\n   hyperlinked. _This_ would add some patches to commitdiff view, which are\n   now IIRC visible only in difftree part now.\n\n * enable sorting tags/heads view by name instead of sorting it by date.\n\n\n5. New views\n\n * Reflog view (most probably limited to heads only). I'm not sure if it is\n   worth time spend on calling git commands to mark unreachable commits for\n   example using strikethrough, and hyperlink reachable. Any ideas how such\n   a view should look like?\n\n * ViewVC-like tree-blame view. There was RFC patch adding tree_blame view\n   some time ago here, on git mailing list. The main problem of course is\n   performance. We could implement tree_blame purely in gitweb as it was\n   done in mentioned patch (having --stdin option to git-ls-tree would\n   help), or add new core command/extend git-blame for directories. There is\n   also a question if we want to find blame for tree entries, or not.\n\n * \"List of the files in given directory, touched by given commit\"\n\n * Perhaps ad Atom feed support as an alternative to RSS, and XOXO as an\n   alternative to OPML.\n\n * Graph of number of changed files in given branch; probably should be\n   cached.\n\n\nX. Proposed improvements to core git commands\n * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.\n * add --follow option to git-rev-list, allow to provide path limiter via\n   stdin (with --stdin option) in git-diff-tree\n * add --numstat option to git-diff; currently only git-apply has it.\n\n\nThoughts? Comments?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28578","messageId":"7v1wpfwg92.fsf@assigned-by-dhcp.cox.net","threadId":"5862","inReplyTo":"egdge3$t12$1@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-11T05:52:57Z","receivedAt":"2006-10-11T05:52:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> 1. Cleanups and refactoring\n>\n>  * HTML and CSS cleanup. All (or almost all) styling should be done using\n>    CSS, and not embedded style or presentation elements. All HTML elements\n>    except perhaps a few should have either class attribute (if such\n>    element can be multiple times on page) or id attribute (if there can be\n>    only one such element). Perhaps some class attributes should be changed\n>    to id attributes. Gitweb has much improved from the incorporation in\n>    this area.\n\nIt scares me when somebody says \"all X should do Y\".  Aiming for\nconsistency and cleanliness is good but taking it to extreme and\nbecoming dogmatic about it isn't.  Let's not repeat the crusade\nagainst redundant links.\n\n>    ... When the new\n>    --grep/--author/--commiter options to git-rev-list hits released version,\n>    perhaps also git_search could be put together with the previous set.\n\nSounds like a good idea, but I think people can (and should)\nstart preparing for it in \"next\"; after all that is what \"next\"\nis for.\n\n>  * Refactor calling a git command and reading it's output into separate\n>    subroutine git_command/git_pipe, so for example if someone _has_ to use\n>    gitweb with ancient Perl version which does not understand list version\n>    of magic \"-|\" open could do it changing only one subroutine. Well, we can\n>    use Git.pm when it hits main release.\n\nI agree this is a good thing to do while refactoring.  There are\ntoo many similar looking code sprinkled all over.  Git.pm is\nalready in the \"master\" and there is nothing cooking in \"next\".\n\n>  * Add simplified git config file parser, which would _read_ only gitweb\n>    entries (and convert them to bool/int if necessary). With this we could\n>    move description, category, export_ok, .hide, cloneurl to config file,\n>    instead of cluttering $GIT_DIR. Or just make it an option (read file\n>    first, if it doesn't exist try config file).\n\nI do not see why you would need anything \"simplified\"; I think\nwriting a .git/config parser purely in Perl is much easier than\nwaiting for libified interface that talks .xs and would run just\nas efficient -- after all Perl is the ideal tool for text file\nprocessing like this.  And I do not particularly worry about\nissues that could arise from two different configuration parsers\nhaving different set of bugs.  The file format is simple enough.\nIt would be a very good addition to Git.pm suite.\n\n>  * Add categories support a la gitweb-xmms2 to the projects list view (and\n>    perhaps also OPML); perhaps with option to use first part of path to\n>    repository as category.\n\nPerhaps; hosting site would want this.\n\n>  * Code highlighting (or generic filter) support in blob view, perhaps as\n>    a feature.\n\nNot particularly interested myself but as long as it would not\nadd huge load on the server I would not much object either.\n\n>  * Crossreferencing in blob view.\n\nLxr is certainly interesting, but I would rather use local \"git grep\".\n\n>  * add summary of number of lines changed for each file (a la darcsview)\n>    in the difftree part of commit and *diff* views, e.g.\n>\n>         blame.c   +1 -0  diff | history | blame\n>\n>    or something like that.\n\nI'll place \"diff --numstat\" to the stack of \"things to do on the\ncore side\".  Should be trivial.\n\n>  * Reflog view (most probably limited to heads only). I'm not sure if it is\n>    worth time spend on calling git commands to mark unreachable commits for\n>    example using strikethrough, and hyperlink reachable. Any ideas how such\n>    a view should look like?\n\nIf the feature is useful, do not be afraid to add core side\nsupport for it.  As long as the proposed core side support is\nreasonable and not too specific to a niche task, that is.\n\n>  * \"List of the files in given directory, touched by given commit\"\n\nHave no idea what you mean.  \"diff-tree -r --name-only $commit\"?\n\n> X. Proposed improvements to core git commands\n>  * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.\n\nNot particularly interested, as it is unclear how the output\nboundary should be marked, but should be trivial to add once we\nknow what the output should look like.\n\n>  * add --follow option to git-rev-list, allow to provide path limiter via\n>    stdin (with --stdin option) in git-diff-tree\n\nThe \"path limiter via stdin\" part is murky.  I would not object\nto \"rev-list --follow=$this_path_at_the_tip $start_at_this_commit\"\nwhich I can see clear semantics for. \n"},{"id":"28592","messageId":"200610111120.55330.jnareb@gmail.com","threadId":"5862","inReplyTo":"7v1wpfwg92.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-11T09:20:54Z","receivedAt":"2006-10-11T09:20:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> 1. Cleanups and refactoring\n>>\n>>  * HTML and CSS cleanup. All (or almost all) styling should be done using\n>>    CSS, and not embedded style or presentation elements. All HTML elements\n>>    except perhaps a few should have either class attribute (if such\n>>    element can be multiple times on page) or id attribute (if there can be\n>>    only one such element). Perhaps some class attributes should be changed\n>>    to id attributes. Gitweb has much improved from the incorporation in\n>>    this area.\n> \n> It scares me when somebody says \"all X should do Y\".  Aiming for\n> consistency and cleanliness is good but taking it to extreme and\n> becoming dogmatic about it isn't.  Let's not repeat the crusade\n> against redundant links.\n\nWell, after writing this part I have checked that we don't use\n\"style\" attribute in gitweb anymore. But we still do use presentational\nelements, like <i>. IMHO we should use CSS for styling.\n\n>>    ... When the new\n>>    --grep/--author/--commiter options to git-rev-list hits released version,\n>>    perhaps also git_search could be put together with the previous set.\n> \n> Sounds like a good idea, but I think people can (and should)\n> start preparing for it in \"next\"; after all that is what \"next\"\n> is for.\n\nUsing --grep/--author/--commiter would have the advantage of to be\neasily able to paginate \"log search\" in gitweb.\n\nI forgot to add splitting git_search into \"log search\" and \"pickaxe search\",\nand perhaps adding \"file search\" aka. \"grep search\" to gitweb.\n \n>>  * Refactor calling a git command and reading it's output into separate\n>>    subroutine git_command/git_pipe, so for example if someone _has_ to use\n>>    gitweb with ancient Perl version which does not understand list version\n>>    of magic \"-|\" open could do it changing only one subroutine. Well, we can\n>>    use Git.pm when it hits main release.\n> \n> I agree this is a good thing to do while refactoring.  There are\n> too many similar looking code sprinkled all over.  Git.pm is\n> already in the \"master\" and there is nothing cooking in \"next\".\n\nI'm not sure if I would like to use Git.pm repository abstraction.\nBut converting gitweb to use Git.pm would be a good idea, I agree.\nAlthough I'd rather have any gitweb patches which need _unreleased_\nfeatures to be in 'next'.\n \nBTW. the Git.pm-ish ideas (config parser, remotes parser, symrefs and\npacked refs parser) should perhaps be added (at least in 'next')\nvia Git.pm.\n\n>>  * Add simplified git config file parser, which would _read_ only gitweb\n>>    entries (and convert them to bool/int if necessary). With this we could\n>>    move description, category, export_ok, .hide, cloneurl to config file,\n>>    instead of cluttering $GIT_DIR. Or just make it an option (read file\n>>    first, if it doesn't exist try config file).\n> \n> I do not see why you would need anything \"simplified\"; I think\n> writing a .git/config parser purely in Perl is much easier than\n> waiting for libified interface that talks .xs and would run just\n> as efficient -- after all Perl is the ideal tool for text file\n> processing like this.  And I do not particularly worry about\n> issues that could arise from two different configuration parsers\n> having different set of bugs.  The file format is simple enough.\n> It would be a very good addition to Git.pm suite.\n\nThere are many INI file parsers in CPAN, but I guess that Git adds\nit's own config file syntax (e.g. branch and remote config:\n  [branch \"quoted branch name with funny characters]\nwhich is not yet documented if I remember correctly) that we want our\nown parser; this would also reduce dependencies.\n\n\"Simplified\" because of not implementing \"extended syntax\" mentioned\nabove, and because implementing only reading config file. It is harder\nto make it write config file, preserving comments etc.\n \nBy the way, would it be better to use CGI like syntax of \n$repo->config(\"gitweb.$key\"), or tie hash?\n\n>>  * Code highlighting (or generic filter) support in blob view, perhaps as\n>>    a feature.\n> \n> Not particularly interested myself but as long as it would not\n> add huge load on the server I would not much object either.\n\nIt should be: as a feature, not perhaps as a feature. Perhaps\nmake highlighting configurable (program to use, filename to mode\nmapping, etc.)\n \n>>  * Crossreferencing in blob view.\n> \n> LXR is certainly interesting, but I would rather use local \"git grep\".\n\nThis is far, far in the queue at least for me. And I'm not sure\nif crossreferencing can be done without creating temporary files,\nsomething we tried to avoid (e.g. creating diffs on-the-fly now).\n \n>>  * add summary of number of lines changed for each file (a la darcsview)\n>>    in the difftree part of commit and *diff* views, e.g.\n>>\n>>         blame.c   +1 -0  diff | history | blame\n>>\n>>    or something like that.\n> \n> I'll place \"diff --numstat\" to the stack of \"things to do on the\n> core side\".  Should be trivial.\n\nThanks. I did wonder why git-apply (!) has \"--numstat\" but git-diff\nhas not... \n\n>>  * \"List of the files in given directory, touched by given commit\"\n> \n> Have no idea what you mean.  \"diff-tree -r --name-only $commit\"?\n\nI'm repeating verbatim someone idea. IIRC it meant adding list\nof affected files (like difftre part of \"commit\" and \"commitdiff\"\nviews) to the \"log\" and \"search\" views...\n \n>> X. Proposed improvements to core git commands\n>>  * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.\n> \n> Not particularly interested, as it is unclear how the output\n> boundary should be marked, but should be trivial to add once we\n> know what the output should look like.\n\nThe output format for git-ls-tree is\n\t<mode> SP <type> SP <object> TAB <file>\nIt is fairly easy to distinguish such line from the\n\t<sha1 of tree-ish>\nline. \n\nThe idea was that \n\techo \"tree-ish 1\" \"tree-ish 2\" | git ls-tree --stdin\noutput would be\n\t<sha1 of tree-ish 1>\n\t<mode> SP <type> SP <object> TAB <file>\n\t...\n\t<mode> SP <type> SP <object> TAB <file>\n\t<sha1 of tree-ish 2>\n\t<mode> SP <type> SP <object> TAB <file>\n\t...\n\t<mode> SP <type> SP <object> TAB <file>\n\nWe could add some records (trees) seperating, for example by NUL\ncharacter like in git-rev-list --headers.\n \n>>  * add --follow option to git-rev-list, allow to provide path limiter via\n>>    stdin (with --stdin option) in git-diff-tree\n> \n> The \"path limiter via stdin\" part is murky.  I would not object\n> to \"rev-list --follow=$this_path_at_the_tip $start_at_this_commit\"\n> which I can see clear semantics for. \n \nYou can provide <tree-ish> or pair of <tree-ish> from stdin for\ngit-diff-tree --stdin. You can provide path limiter _only_ as an\nargument to git-diff-tree. Proposed extension is to be able to\nuse\n\t<tree-ish> [<tree-ish>] [<path>...]\nfrom stdin, perhaps _forcing_ to use\n\t <tree-ish> [<tree-ish>] ['--' <path>...]\nsyntax.\n\nAlternatively, change semantics of path limiter if path limiter\nmatch _exactly_ --follow argument.\n-- \nJakub Narebski\nPoland\n"},{"id":"28604","messageId":"egj1g6$bk6$1@sea.gmane.org","threadId":"5862","inReplyTo":"egdge3$t12$1@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-11T15:09:59Z","receivedAt":"2006-10-11T15:09:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n>  * Graph of number of changed files in given branch; probably should be\n>    cached.\n\nSee for example StatCVS and FishEye\n  http://www-128.ibm.com/developerworks/java/library/j-statcvs/\n  http://statcvs.sourceforge.net/statcvs-stats/\n\n  http://fisheye.codehaus.org/browse/activecluster\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28646","messageId":"egjtba$33o$1@sea.gmane.org","threadId":"5862","inReplyTo":"egdge3$t12$1@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-11T23:05:16Z","receivedAt":"2006-10-11T23:05:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"4. New features\n\n * Better support for symlinks in the \"tree\" view, perhaps in the\n   \"_filename_ -> _target_\" form instead of simply \"_filename_\"\n   if the symlink is relative, and the target is inside repository\n   (not checking if it exists), \"_filename_ -> target\" otherwise.\n   Needs some normalizing (removing of '/./' and '/../') of the symlink\n   target.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28659","messageId":"7vy7rlq2aq.fsf@assigned-by-dhcp.cox.net","threadId":"5862","inReplyTo":"7v1wpfwg92.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-12T10:03:09Z","receivedAt":"2006-10-12T10:03:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n>\n>>  * add summary of number of lines changed for each file (a la darcsview)\n>>    in the difftree part of commit and *diff* views, e.g.\n>>\n>>         blame.c   +1 -0  diff | history | blame\n>>\n>>    or something like that.\n>\n> I'll place \"diff --numstat\" to the stack of \"things to do on the\n> core side\".  Should be trivial.\n\nThis is only lightly tested. I haven't done test suite nor\ndocumentation, which the list should be able to take care of,\nnow my git day for this week is over ;-).\n\n-- >8 --\n[PATCH] diff --numstat\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n combine-diff.c |    9 ++++++---\n diff.c         |   29 +++++++++++++++++++++++++++--\n diff.h         |   15 ++++++++-------\n 3 files changed, 41 insertions(+), 12 deletions(-)\n\ndiff --git a/combine-diff.c b/combine-diff.c\nindex 46d9121..65c7868 100644\n--- a/combine-diff.c\n+++ b/combine-diff.c\n@@ -856,8 +856,10 @@ void diff_tree_combined(const unsigned c\n \t\t/* show stat against the first parent even\n \t\t * when doing combined diff.\n \t\t */\n-\t\tif (i == 0 && opt->output_format & DIFF_FORMAT_DIFFSTAT)\n-\t\t\tdiffopts.output_format = DIFF_FORMAT_DIFFSTAT;\n+\t\tint stat_opt = (opt->output_format &\n+\t\t\t\t(DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT));\n+\t\tif (i == 0 && stat_opt)\n+\t\t\tdiffopts.output_format = stat_opt;\n \t\telse\n \t\t\tdiffopts.output_format = DIFF_FORMAT_NO_OUTPUT;\n \t\tdiff_tree_sha1(parent[i], sha1, \"\", &diffopts);\n@@ -887,7 +889,8 @@ void diff_tree_combined(const unsigned c\n \t\t\t}\n \t\t\tneedsep = 1;\n \t\t}\n-\t\telse if (opt->output_format & DIFF_FORMAT_DIFFSTAT)\n+\t\telse if (opt->output_format &\n+\t\t\t (DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT))\n \t\t\tneedsep = 1;\n \t\tif (opt->output_format & DIFF_FORMAT_PATCH) {\n \t\t\tif (needsep)\ndiff --git a/diff.c b/diff.c\nindex fb82432..2dcad19 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -795,6 +795,23 @@ static void show_stats(struct diffstat_t\n \t       set, total_files, adds, dels, reset);\n }\n \n+static void show_numstat(struct diffstat_t* data, struct diff_options *options)\n+{\n+\tint i;\n+\n+\tfor (i = 0; i < data->nr; i++) {\n+\t\tstruct diffstat_file *file = data->files[i];\n+\n+\t\tprintf(\"%d\\t%d\\t\", file->added, file->deleted);\n+\t\tif (options->line_termination &&\n+\t\t    quote_c_style(file->name, NULL, NULL, 0))\n+\t\t\tquote_c_style(file->name, NULL, stdout, 0);\n+\t\telse\n+\t\t\tfputs(file->name, stdout);\n+\t\tputchar(options->line_termination);\n+\t}\n+}\n+\n struct checkdiff_t {\n \tstruct xdiff_emit_state xm;\n \tconst char *filename;\n@@ -1731,6 +1748,7 @@ int diff_setup_done(struct diff_options \n \t\t\t\t      DIFF_FORMAT_CHECKDIFF |\n \t\t\t\t      DIFF_FORMAT_NO_OUTPUT))\n \t\toptions->output_format &= ~(DIFF_FORMAT_RAW |\n+\t\t\t\t\t    DIFF_FORMAT_NUMSTAT |\n \t\t\t\t\t    DIFF_FORMAT_DIFFSTAT |\n \t\t\t\t\t    DIFF_FORMAT_SUMMARY |\n \t\t\t\t\t    DIFF_FORMAT_PATCH);\n@@ -1740,6 +1758,7 @@ int diff_setup_done(struct diff_options \n \t * recursive bits for other formats here.\n \t */\n \tif (options->output_format & (DIFF_FORMAT_PATCH |\n+\t\t\t\t      DIFF_FORMAT_NUMSTAT |\n \t\t\t\t      DIFF_FORMAT_DIFFSTAT |\n \t\t\t\t      DIFF_FORMAT_CHECKDIFF))\n \t\toptions->recursive = 1;\n@@ -1828,6 +1847,9 @@ int diff_opt_parse(struct diff_options *\n \telse if (!strcmp(arg, \"--patch-with-raw\")) {\n \t\toptions->output_format |= DIFF_FORMAT_PATCH | DIFF_FORMAT_RAW;\n \t}\n+\telse if (!strcmp(arg, \"--numstat\")) {\n+\t\toptions->output_format |= DIFF_FORMAT_NUMSTAT;\n+\t}\n \telse if (!strncmp(arg, \"--stat\", 6)) {\n \t\tchar *end;\n \t\tint width = options->stat_width;\n@@ -2602,7 +2624,7 @@ void diff_flush(struct diff_options *opt\n \t\tseparator++;\n \t}\n \n-\tif (output_format & DIFF_FORMAT_DIFFSTAT) {\n+\tif (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_NUMSTAT)) {\n \t\tstruct diffstat_t diffstat;\n \n \t\tmemset(&diffstat, 0, sizeof(struct diffstat_t));\n@@ -2612,7 +2634,10 @@ void diff_flush(struct diff_options *opt\n \t\t\tif (check_pair_status(p))\n \t\t\t\tdiff_flush_stat(p, options, &diffstat);\n \t\t}\n-\t\tshow_stats(&diffstat, options);\n+\t\tif (output_format & DIFF_FORMAT_NUMSTAT)\n+\t\t\tshow_numstat(&diffstat, options);\n+\t\tif (output_format & DIFF_FORMAT_DIFFSTAT)\n+\t\t\tshow_stats(&diffstat, options);\n \t\tseparator++;\n \t}\n \ndiff --git a/diff.h b/diff.h\nindex b48c991..435c70c 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -26,20 +26,21 @@ typedef void (*diff_format_fn_t)(struct \n \n #define DIFF_FORMAT_RAW\t\t0x0001\n #define DIFF_FORMAT_DIFFSTAT\t0x0002\n-#define DIFF_FORMAT_SUMMARY\t0x0004\n-#define DIFF_FORMAT_PATCH\t0x0008\n+#define DIFF_FORMAT_NUMSTAT\t0x0004\n+#define DIFF_FORMAT_SUMMARY\t0x0008\n+#define DIFF_FORMAT_PATCH\t0x0010\n \n /* These override all above */\n-#define DIFF_FORMAT_NAME\t0x0010\n-#define DIFF_FORMAT_NAME_STATUS\t0x0020\n-#define DIFF_FORMAT_CHECKDIFF\t0x0040\n+#define DIFF_FORMAT_NAME\t0x0100\n+#define DIFF_FORMAT_NAME_STATUS\t0x0200\n+#define DIFF_FORMAT_CHECKDIFF\t0x0400\n \n /* Same as output_format = 0 but we know that -s flag was given\n  * and we should not give default value to output_format.\n  */\n-#define DIFF_FORMAT_NO_OUTPUT\t0x0080\n+#define DIFF_FORMAT_NO_OUTPUT\t0x0800\n \n-#define DIFF_FORMAT_CALLBACK\t0x0100\n+#define DIFF_FORMAT_CALLBACK\t0x1000\n \n struct diff_options {\n \tconst char *filter;\n-- \n1.4.3.rc2.gdce3\n"},{"id":"28741","messageId":"200610132155.25533.jnareb@gmail.com","threadId":"5862","inReplyTo":"7vy7rlq2aq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-13T19:55:25Z","receivedAt":"2006-10-13T19:55:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> This is only lightly tested. I haven't done test suite nor\n> documentation, which the list should be able to take care of,\n> now my git day for this week is over ;-).\n> \n> -- >8 --\n> [PATCH] diff --numstat\n\nDoes for example\n\n\tgit diff-tree --numstat --patch-with-stat <tree-ish>\n\nor\n\n\tgit diff-tree --numstat -p <tree-ish>\n\nwork as expected, i.e. prepend diffstat in machine friendly (numstat)\nformat? What happens if one uses both --stat and --numstat?\n\n-- >8 --\nDocumenting diff --numstat\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\nIs it enough documentation? Should we provide also numstat format\ndescription in Documentation/diff-format.txt?\n\n Documentation/diff-options.txt |    5 +++++\n diff.h                         |    1 +\n 2 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex 7b7b9e8..e112172 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -16,6 +16,11 @@\n \tThe width of the filename part can be controlled by\n \tgiving another width to it separated by a comma.\n \n+--numstat::\n+\tSimilar to \\--stat, but shows number of added and\n+\tdeleted lines in decimal notation and pathname without\n+\tabbreviation, to make it more machine friendly.\n+\n --summary::\n \tOutput a condensed summary of extended header information\n \tsuch as creations, renames and mode changes.\ndiff --git a/diff.h b/diff.h\nindex 435c70c..ce3058e 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -171,6 +171,7 @@ #define COMMON_DIFF_OPTIONS_HELP \\\n \"  --patch-with-raw\\n\" \\\n \"                output both a patch and the diff-raw format.\\n\" \\\n \"  --stat        show diffstat instead of patch.\\n\" \\\n+\"  --numstat     show numeric diffstat instead of patch.\\n\" \\\n \"  --patch-with-stat\\n\" \\\n \"                output a patch and prepend its diffstat.\\n\" \\\n \"  --name-only   show only names of changed files.\\n\" \\\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28800","messageId":"egtjda$8qg$1@sea.gmane.org","threadId":"5862","inReplyTo":"egj1g6$bk6$1@sea.gmane.org","subject":"[RFC] Ideas for new \"stats\" view in gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-15T15:17:18Z","receivedAt":"2006-10-15T15:17:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Jakub Narebski wrote:\n> \n>>  * Graph of number of changed files in given branch; probably should be\n>>    cached.\n> \n> See for example StatCVS and FishEye\n>   http://www-128.ibm.com/developerworks/java/library/j-statcvs/\n>   http://statcvs.sourceforge.net/statcvs-stats/\n> \n>   http://fisheye.codehaus.org/browse/activecluster\n\nSee also StatCVS-XML (http://statcvs-xml.berlios.de) and SvnStat\n(http://svnstat.sourceforge.net), both derivatives of StatCVS, with\na few plots/charts added. If you know other graphical SCM statistics\ntools, please mention them.\n\nWould additional \"stats\" view help? Does some bit of stats help (well,\nbesides diffstat in commitdiff; perhaps later graphical diffstat in\ngitweb)?\n\nFor example all (I think) above projects include plot of \"size\" (usually in\nlines of code) of repository versus time, sometimes split into few top\nauthors or few top subdirectories; sometimes limited to some subdirectory or\neven to some file only, together with the plot of \"commit volume\" (usually\nnumber of commits per unit, e.g. number of commits per day, but it could be\nnumbers of files changed and/or number of lines added/deleted) vs time.\nTags are marked on the time scale. This supposedly helps to realize if\nproject/part of project/individual file is in development, refactoring or\nmaintenace stage. And graph with different top authors plotted using\ndifferent lines visualises which were active during which point of project\nhistory. I'm not sure what \"commit volume\" plot tells us.\n\nNext there are various tables and plots gathering statistics about authors:\nlines of code + percentage, numbers of changes (commits) + percentage,\naverage number of lines per change, ratio of modifications to adding new\ncode. Git has git-shortlog for creating similar summary. That probably\nhelps to realize who takes what part in development of project. And there\ncan be similar tables, charts and plots but with module/subdirectory/file\ninstead of author. For example top files with respect to size, changes,\nor number of revisions in history.\n\nThen there are IMVHO not very useful (except for satisfying idle curiosity)\nhistograms of activity (either number of commits, or number of changed\nlines) per hour of day, or per day of week, or per month of year (in older\nprojects).\n\n\nThere are some other plots, charts, tables, graphs... Please do tell which\nones would be good to have in gitweb.\n\nBTW. we most certainly would have to use some cache I guess... and we have\njust removed the need for temporary files for creating diffs...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}