Jakub Narebski venit, vidit, dixit 21.02.2011 23:06: > On Tue, 15 Feb 2011, Michael J Gruber wrote: >> Jakub Narebski venit, vidit, dixit 14.02.2011 20:39: > >>> Now that we are talking about future of git, including breaking some >>> of backwards compatibility bugs / misdesigns for 1.8.0, perhaps it is >>> the time to discuss long term goals and the future of gitweb. >> ... >>> Current requirements are: >>> - Perl 5.8.x (for proper Unicode / UTF-8 support) >>> - core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,... >>> - non-core Perl modules optional, needed for some of extra features >>> - backward compatibility (query params and path_info URLs) >> >> I'd second that this is important for adaption by some main users. > > You mean here backward compatibility of API (i.e. old links keep working), > isn't it? Yep, the last item. > >>> - easy installation even without admin rights >>> - scanning for repositories (as an option) >>> - lightweight >> >> All of these are important for instaweb also. > > Nowadays git-instaweb uses _installed_ gitweb, so neither easy > installation, nor installing / running without admin rights is necessary > for use of gitweb in git-instaweb. Strictly speaking neither is scanning > for repositories; I think git-isnatweb could generate file with list of > repositories (with repository) to show. Cool, I didn't know, but it's a great feature. By "easy installation" I mean being able to use it without having to configure a "central" web server, i.e. just the way a git+gitweb in $HOME can run instaweb without admin rights. >> I consider instaweb a very >> underrated feature! (It also needs some works of love, not just >> appreciation, of course.) > > Beside adding support for new web servers (like recently added 'plackup'), > what do you thing needs to be done? E.g., using an installed gitweb - I just learned it does that already! Also, the graph viewer, i.e. including it as a module with the same "looks" as the rest of gitweb. I don't know how customisable gitweb's layout is right now (CSS). That might be important for some. Personally, whenever I'm on the more "modern" repo hosters, I'm longing for the clean interface and high information density of gitweb. >>> 1. Splitting gitweb into modules (packages), for better maintainability. >> >> Also, this may help including other optional parts. The graph viewer as >> used on repo.or.cz sets gitweb apart from quite a few alternatives and >> would be used more widely if it were an optional module shipping with >> gitweb. Just imagine instaweb with graphs ;) >> Also, being part of gitweb, the viewer may attract a few coders. > > Well, adding anything major (like e.g. write functionality, output caching; > perhaps graph of history is also in this category) really require split > gitweb. It is getting hard to maintain gitweb as it is now. 100% agreed. Also, smaller modules make it easier for new gitweb contributors to join and help. Cheers, Michael -- 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