Jakub Narebski <jnareb@xxxxxxxxx> writes: > 1. Cleanups and refactoring > > * HTML and CSS cleanup. All (or almost all) styling should be done using > CSS, and not embedded style or presentation elements. All HTML elements > except perhaps a few should have either class attribute (if such > element can be multiple times on page) or id attribute (if there can be > only one such element). Perhaps some class attributes should be changed > to id attributes. Gitweb has much improved from the incorporation in > this area. It scares me when somebody says "all X should do Y". Aiming for consistency and cleanliness is good but taking it to extreme and becoming dogmatic about it isn't. Let's not repeat the crusade against redundant links. > ... When the new > --grep/--author/--commiter options to git-rev-list hits released version, > perhaps also git_search could be put together with the previous set. Sounds like a good idea, but I think people can (and should) start preparing for it in "next"; after all that is what "next" is for. > * Refactor calling a git command and reading it's output into separate > subroutine git_command/git_pipe, so for example if someone _has_ to use > gitweb with ancient Perl version which does not understand list version > of magic "-|" open could do it changing only one subroutine. Well, we can > use Git.pm when it hits main release. I agree this is a good thing to do while refactoring. There are too many similar looking code sprinkled all over. Git.pm is already in the "master" and there is nothing cooking in "next". > * Add simplified git config file parser, which would _read_ only gitweb > entries (and convert them to bool/int if necessary). With this we could > move description, category, export_ok, .hide, cloneurl to config file, > instead of cluttering $GIT_DIR. Or just make it an option (read file > first, if it doesn't exist try config file). I do not see why you would need anything "simplified"; I think writing a .git/config parser purely in Perl is much easier than waiting for libified interface that talks .xs and would run just as efficient -- after all Perl is the ideal tool for text file processing like this. And I do not particularly worry about issues that could arise from two different configuration parsers having different set of bugs. The file format is simple enough. It would be a very good addition to Git.pm suite. > * Add categories support a la gitweb-xmms2 to the projects list view (and > perhaps also OPML); perhaps with option to use first part of path to > repository as category. Perhaps; hosting site would want this. > * Code highlighting (or generic filter) support in blob view, perhaps as > a feature. Not particularly interested myself but as long as it would not add huge load on the server I would not much object either. > * Crossreferencing in blob view. Lxr is certainly interesting, but I would rather use local "git grep". > * add summary of number of lines changed for each file (a la darcsview) > in the difftree part of commit and *diff* views, e.g. > > blame.c +1 -0 diff | history | blame > > or something like that. I'll place "diff --numstat" to the stack of "things to do on the core side". Should be trivial. > * Reflog view (most probably limited to heads only). I'm not sure if it is > worth time spend on calling git commands to mark unreachable commits for > example using strikethrough, and hyperlink reachable. Any ideas how such > a view should look like? If the feature is useful, do not be afraid to add core side support for it. As long as the proposed core side support is reasonable and not too specific to a niche task, that is. > * "List of the files in given directory, touched by given commit" Have no idea what you mean. "diff-tree -r --name-only $commit"? > X. Proposed improvements to core git commands > * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree. Not particularly interested, as it is unclear how the output boundary should be marked, but should be trivial to add once we know what the output should look like. > * add --follow option to git-rev-list, allow to provide path limiter via > stdin (with --stdin option) in git-diff-tree The "path limiter via stdin" part is murky. I would not object to "rev-list --follow=$this_path_at_the_tip $start_at_this_commit" which I can see clear semantics for. - 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