{"thread":{"id":"23468","subject":"GSoC 2010: \"Integrated Web Client for git\" proposal","startedAt":"2010-04-15T04:30:44Z","lastAt":"2010-04-23T09:44:33Z","messageCount":39,"participants":["Christian Couder","Jakub Narebski","Petr Baudis","Pavan Kumar Sunkara","Matthieu Moy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139550","messageId":"201004150630.44300.chriscool@tuxfamily.org","threadId":"23468","inReplyTo":null,"subject":"GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-04-15T04:30:44Z","receivedAt":"2010-04-15T04:30:44Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi!\n\nPavan Kumar Sunkara sent an email on the git mailing list a few days ago about \nhis GSoC proposal:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/144658/\n\nHis proposal is based on the project he already started:\n\nhttp://github.com/pkumar/gittor\n\nThere have been discussions about it on the GSoC web app and in some private \nemails.\n\nPossible GSoC mentors for this proposal don't want yet another web interface, \nthey want an existing interface to be improved on. As the obvious choice is to \nimprove gitweb, the current result from the discussions is that the proposal \nshould be changed so that the integrated web client is developed in Perl into \nor alongside gitweb.\n\nPavan agreed to rewrite his proposal according to that and Petr and myself \nvolunteered to co-mentor him.\n\nIt was suggested that improving Gitalist \n(http://wiki.catalystframework.org/wiki/gitalist) would be a better choice. \nBut this was rejected because Gitalist is too much different from gitweb so it \ncould not replace it for many people now using gitweb.\n\nBest regards,\nChristian.\n\n\n \n"},{"id":"139794","messageId":"201004180246.18263.jnareb@gmail.com","threadId":"23468","inReplyTo":"201004150630.44300.chriscool@tuxfamily.org","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-18T00:46:16Z","receivedAt":"2010-04-18T00:46:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia czwartek 15. kwietnia 2010 06:30, Christian Couder napisał:\n> Hi!\n> \n> Pavan Kumar Sunkara sent an email on the git mailing list a few days ago about \n> his GSoC proposal:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/144658/\n\nI would really prefer if Pavan just *wrote* the text of his \"Integrated\nWeb Client for git\" proposal for GSoC 2010 in email, instead of providing\nlink to it; link that requires signing-in.\n\n This proposal aims at creating a multi-purpose HTML based GUI client\n for git. This client intends in reducing the work needed to be done\n by a developer while working on a git repository. This is not another\n gitweb or gitorious but it also contains their functionalities as\n submodules.\n \n The project goal is to try and implement a integrated multi-purpose\n HTML based GUI client for git. It contains two parts which are\n crucial while working on a git repository, Read and Write.\n\n * Read means browse through the code and repository\n * Write means working on the code and repository\n\n Also, in the future others will be able to develop more functionalities\n for this client with the help of the framework like structure of this\n project.\n\nIt is not entirely sure what this \"Web Client\" is meant to do. Is it\nmainly meant as web interface to managing repositories (webmin for git),\nsomething that GitHub, Gitorious, InDefero, Girocco all include? This\ncould mean web interface to configuring gitosis / gitolite. Or is it\nmeant as web analogue of git-gui: a committool, with ability to create\nnew commits, perhaps to edit files (and add them, delete them, move them\naround), a bit like ikiwiki with Git backend, or other Git based wikis\nand blogs? Or is it something else?\n\n> His proposal is based on the project he already started:\n> \n> http://github.com/pkumar/gittor\n> \n> There have been discussions about it on the GSoC web app and in some private \n> emails.\n> \n> Possible GSoC mentors for this proposal don't want yet another web interface, \n> they want an existing interface to be improved on. As the obvious choice is to \n> improve gitweb, the current result from the discussions is that the proposal \n> should be changed so that the integrated web client is developed in Perl into \n> or alongside gitweb.\n\nIt could be a waste to duplicate functionality that is already present\nin gitweb, at least for GSoC (having yet another web interface for git,\nthis time in Python, could be a good thing... if the web interface would\nbe developed further). \n\nAs to integrating \"Web Client for Git\" with gitweb, there exists at least\na few possible ways to do this:\n\n1. Keep \"Web Client\" separate for gitweb, and make use of gitweb \n hooks/plugin system like $feature{'actions'}. This might require\n adding new \"hooks\" to gitweb.\n\n The advantage is that \"Web Client\" can be written in any language,\n not necessary Perl. The disadvantage that if it is written in Perl,\n some code might be duplicated. It might be hard to write generic\n hooks - the \"Web Client\" could be not as well integrated with gitweb.\n\n2. Write \"Web Client\" as a Perl module, like 'gitweb/cache.pm' in the\n http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu\n and 'require' this file as needed, guarded by global variable or\n %feature.\n\n The advantage is possible tighter integration. I am not sure about\n being able to use code from gitweb in \"Web Client\". It also requires\n using Perl, and might require using some contortions if the problem\n would be naturally split into multiple modules: there can be multiple\n modules, but it could be better to have them in one file.\n\n3. Split Gitweb, add \"Web Client\" as one of modules. Might be best\n from the purity point of view, but is practical only if it is\n integrated in gitweb. That would require getting gitweb maintainer\n out of GSoC. Also I am not sure how feaible this approach would be.\n\n> \n> Pavan agreed to rewrite his proposal according to that and Petr and myself \n> volunteered to co-mentor him.\n> \n> It was suggested that improving Gitalist \n> (http://wiki.catalystframework.org/wiki/gitalist) would be a better choice. \n> But this was rejected because Gitalist is too much different from gitweb so it \n> could not replace it for many people now using gitweb.\n\nTrue, I don't think that e.g. git.kernel.org or repo.or.cz could install\nCatalyst and Git::PurePerl and use Gitalist instead of gitweb...\n\nP.S. If I remember correctly Gitalist was based out of last gitweb version\n before it got bundled with git. I wonder if they caught up to the\n modern gitweb features (snapshots, Atom/RSS feeds, basic submodule\n support, handling images, incremental blame, grep and pickaxe search,\n etc.).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139800","messageId":"20100418005917.GO10939@machine.or.cz","threadId":"23468","inReplyTo":"201004180246.18263.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-18T00:59:17Z","receivedAt":"2010-04-18T00:59:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:\n> Or is it\n> meant as web analogue of git-gui: a committool, with ability to create\n> new commits, perhaps to edit files (and add them, delete them, move them\n> around), a bit like ikiwiki with Git backend, or other Git based wikis\n> and blogs?\n\nYes. Though it is probably supposed to be real Git frontend with Git\nsemantics, not something more abstract with Git under the hood.\n\n> 1. Keep \"Web Client\" separate for gitweb, and make use of gitweb \n> hooks/plugin system like $feature{'actions'}. This might require\n> adding new \"hooks\" to gitweb.\n> \n> The advantage is that \"Web Client\" can be written in any language,\n> not necessary Perl. The disadvantage that if it is written in Perl,\n> some code might be duplicated. It might be hard to write generic\n> hooks - the \"Web Client\" could be not as well integrated with gitweb.\n> \n> 2. Write \"Web Client\" as a Perl module, like 'gitweb/cache.pm' in the\n> http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu\n> and 'require' this file as needed, guarded by global variable or\n> %feature.\n> \n> The advantage is possible tighter integration. I am not sure about\n> being able to use code from gitweb in \"Web Client\". It also requires\n> using Perl, and might require using some contortions if the problem\n> would be naturally split into multiple modules: there can be multiple\n> modules, but it could be better to have them in one file.\n\nI think (2) is only infinitesimally better than (1) if you can't call\nall the gitweb methods from your module anyway. For me, the main worry\nis maintaining some consistent UI for the user (graphical and URI-wise)\nand (2) can accomplish this really only in a limited way unless you go\nmuch further with the modularization first.\n\n> 3. Split Gitweb, add \"Web Client\" as one of modules. Might be best\n> from the purity point of view, but is practical only if it is\n> integrated in gitweb. That would require getting gitweb maintainer\n> out of GSoC. Also I am not sure how feaible this approach would be.\n\nWould it be really required to get gitweb maintainer out of GSoC in\norder to go this way? Why?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139802","messageId":"201004180324.54722.jnareb@gmail.com","threadId":"23468","inReplyTo":"20100418005917.GO10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-18T01:24:53Z","receivedAt":"2010-04-18T01:24:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, Apr 18, Petr Baudis wrote:\n> On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:\n\n> > Or is it\n> > meant as web analogue of git-gui: a committool, with ability to create\n> > new commits, perhaps to edit files (and add them, delete them, move them\n> > around), a bit like ikiwiki with Git backend, or other Git based wikis\n> > and blogs?\n> \n> Yes. Though it is probably supposed to be real Git frontend with Git\n> semantics, not something more abstract with Git under the hood.\n\nHmmm... doesn't look so easy. What to do about simultaneous access\n(what webmin does?), and working directory (what ikiwiki does?)?\n \n> > 1. Keep \"Web Client\" separate for gitweb, and make use of gitweb \n> > hooks/plugin system like $feature{'actions'}. This might require\n> > adding new \"hooks\" to gitweb.\n> > \n> > The advantage is that \"Web Client\" can be written in any language,\n> > not necessary Perl. The disadvantage that if it is written in Perl,\n> > some code might be duplicated. It might be hard to write generic\n> > hooks - the \"Web Client\" could be not as well integrated with gitweb.\n> > \n> > 2. Write \"Web Client\" as a Perl module, like 'gitweb/cache.pm' in the\n> > http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu\n> > and 'require' this file as needed, guarded by global variable or\n> > %feature.\n> > \n> > The advantage is possible tighter integration. I am not sure about\n> > being able to use code from gitweb in \"Web Client\". It also requires\n> > using Perl, and might require using some contortions if the problem\n> > would be naturally split into multiple modules: there can be multiple\n> > modules, but it could be better to have them in one file.\n> \n> I think (2) is only infinitesimally better than (1) if you can't call\n> all the gitweb methods from your module anyway. For me, the main worry\n> is maintaining some consistent UI for the user (graphical and URI-wise)\n> and (2) can accomplish this really only in a limited way unless you go\n> much further with the modularization first.\n\nWell, you can always add some of \"Web Client\" functionality directly\nto gitweb (for example dispatch must be, I think, in gitweb). Or you\ncan (ab)use \"do $gitwebgui_pm;\" instead of \"require $gitwebgui_pm;\",\nlike in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3\n(second chunk).\n\nOTOH we can always make gitweb \"use Git;\" and move some of its routines,\nto it after generalization (e.g. config management using single run of\n\"git config -l -z\", unquoting paths, parsing commit/tag/ls-tree/difftree\netc., date parsing and conversion).\n\n\nBTW. the major thing that prevented me from using Git.pm was the few\nplaces that gitweb uses pipeline, or needs to redirect STDERR to \n/dev/null. Also t9700-perl-git.sh test doesn't test command_output_pipe\nand the like. \n\n> > 3. Split Gitweb, add \"Web Client\" as one of modules. Might be best\n> > from the purity point of view, but is practical only if it is\n> > integrated in gitweb. That would require getting gitweb maintainer\n> > out of GSoC. Also I am not sure how feaible this approach would be.\n> \n> Would it be really required to get gitweb maintainer out of GSoC in\n> order to go this way? Why?\n\nWell, at least someone who would be able to manage integrating split\ngitweb. I think that splitting gitweb, and doing it well, is quite\noutside this GSoC 2010 proposal: it would be too much. \n\n-- \nJakub Narebski\nPoland\n"},{"id":"139803","messageId":"20100418021223.GP10939@machine.or.cz","threadId":"23468","inReplyTo":"201004180324.54722.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-18T02:12:23Z","receivedAt":"2010-04-18T02:12:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:\n> On Sun, Apr 18, Petr Baudis wrote:\n> > On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:\n> \n> > > Or is it\n> > > meant as web analogue of git-gui: a committool, with ability to create\n> > > new commits, perhaps to edit files (and add them, delete them, move them\n> > > around), a bit like ikiwiki with Git backend, or other Git based wikis\n> > > and blogs?\n> > \n> > Yes. Though it is probably supposed to be real Git frontend with Git\n> > semantics, not something more abstract with Git under the hood.\n> \n> Hmmm... doesn't look so easy. What to do about simultaneous access\n> (what webmin does?), and working directory (what ikiwiki does?)?\n\n I would expect it to work the same as if you work in single working\ncopy from multiple shells. If multiple people want to collaborate, each\nshould have their own clone to begin with.\n\n> Well, you can always add some of \"Web Client\" functionality directly\n> to gitweb (for example dispatch must be, I think, in gitweb).\n\nBut I don't think you can reasonably separate a major portion of web\nclient that would not depend on gitweb functions like href(), format*()\netc. all over the map.\n\n> Or you\n> can (ab)use \"do $gitwebgui_pm;\" instead of \"require $gitwebgui_pm;\",\n> like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3\n> (second chunk).\n\nThis already occured to me, yes. It's tempting to have this as the\nemergency way out, shall other things fail. But .\n\n> OTOH we can always make gitweb \"use Git;\" and move some of its routines,\n> to it after generalization (e.g. config management using single run of\n> \"git config -l -z\", unquoting paths, parsing commit/tag/ls-tree/difftree\n> etc., date parsing and conversion).\n\nYes, but not things like href(), git_header_html() and other absolutely\nessential routines.\n\n> > > 3. Split Gitweb, add \"Web Client\" as one of modules. Might be best\n> > > from the purity point of view, but is practical only if it is\n> > > integrated in gitweb. That would require getting gitweb maintainer\n> > > out of GSoC. Also I am not sure how feaible this approach would be.\n> > \n> > Would it be really required to get gitweb maintainer out of GSoC in\n> > order to go this way? Why?\n> \n> Well, at least someone who would be able to manage integrating split\n> gitweb. I think that splitting gitweb, and doing it well, is quite\n> outside this GSoC 2010 proposal: it would be too much. \n\nThis was my hesitation at the beginning, but I'm not really sure if\nit's really so hard, _if_ we resist the temptation to snowball unrelated\ncleanups on top of it. Conceptually, it isn't really hard to do, is it?\nThe only tricky thing would be making sure instaweb still works and\ninstallation is still easy, but I don't see anything really difficult in\nthis area either...?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139818","messageId":"n2le72faaa81004180152pb84cef2cn2a7eb95da64420b1@mail.gmail.com","threadId":"23468","inReplyTo":"20100418021223.GP10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-18T08:52:20Z","receivedAt":"2010-04-18T08:52:20Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"Here is my rewritten proposal as Christian and Petr asked me to write.\nPlease go through this.\n\nThanks\n\n-pavan\n\n=====================================================\n\nSplitting gitweb and developing write functionalites\nStudent: Pavan Kumar Sunkara\n\nThis project aims at splitting and organising the 6800 lines code of\ngitweb.pl into a nicely structured set of files. Not only providing\nthe browsing functionalities in gitweb, but it also aims at developing\nfunctionalities for working on a git repository.\n\nFirst I will describe my project goals, giving an overview of what I\nwould like to contribute to git. Second I will give the proposed time\nline of the project which includes all the information about the\nproject. Lastly I will give some information about myself.\n\n\nProject Goals\n\n1.What is the goal of your project?\nThe project goal is to try and implement write functionalities into\ngitweb along with it's browsing functionalities. It also aims at\nsplitting and organising the structure of gitweb perl script.\n\nI would like to split the gitweb script in such a way that, in the\nfuture others will be able to develop more functionalities for gitweb\n(let it be 'read' or 'write' actions) with the help of the framework\nlike structure of the new gitweb.\n\n'read' means browsing through the code and repository\n'write' means working on the code and repository.\n\n2.How would you measure its success or failure?\nThere are two parameters which would majorly determine the success or\nfailure of the project.\n\n * Splitting gitweb such that there should be no problem with the\ninstallation of gitweb across cross servers and cross systems.\n * It should be possible that the new gitweb requires less time to\nwork on a git repository than any other git client.\n * User friendly graphical interface with smart UI design when\ncompared to any other git clients or browsers.\n\n3.Describe your project in more detail.\nI would like to split the currently 6800 long piece of code in\ngitweb.pl perl script into small files which will result in better\nreadability, maintainability and modifiability. The file structure of\nthe new gitweb is given below and I will explain the working after it.\n\n(From now on, I would like to call the actions of gitweb as modules of gitweb)\n\na) File Structure:\n\n * gitweb.pl -- Main script parsing urls and calling required modules\n * gitweb.tpl -- The template of the web page (GUI) in which\nmodules are embedded\n * gitweb.css -- The style for the gitweb pages.\n * gitweb.js -- javascript to make gitweb more interactive\n * modules (dir) -- directory containing the write and read modules.\n * lib (dir) -- some basic files like config, error_handler,\ntemplater, redirecter, htmlHelper etc..\n\nThe current gitweb makefile makes a gitweb.cgi from the perl script\nand requires apache or lighttpd server for it's working. I would like\nto continue this process but the change will be in the gitweb perl\nscript. The new script includes config and other basic files, checks\nthe URL, parses it, detects the module, manage session and includes\nthe proper module. It then retreives the output of the module and\nsubstitutes it with the gitweb.tpl template file string and gives out\na proper HTML, CSS web page. It also contains some basic library files\nin the lib directory. The new gitweb uses session variables to track\nsome of the variables rather than including them in the url. The write\nmodules need not be working in a gitweb installation like repo.or.cz,\nso we will also have an option to disable the write modules.\n\nb) Write modules of the client:\n\n 1. Add Existing repositories to the gitweb -- This will list the\ngiven repo into gitweb config\n 2. Create new/Clone repositories into a given path [git init | git\nclone] -- This will create new repo and list it\n 3. Add/Remove/Move files [git add | git rm | git mv]\n 4. Stage/Unstage files [git add | git reset]\n 5. Add files to ignore list when u click on 'Ignore' link\n 6. Discard changes to a file in working copy [git reset]\n 7. Commit to the repository with a log message and an optional\nsign-off [git commit]\n 8. Switch branches [git branch]\n 9. A simple branch merging* [git merge]\n 10. Creating tags [git tag]\n 11. Checkout code to a specific commit or branch or tag [git checkout]\n 12. Push to a remote branch [git push]\n 13. Fetch/Pull from a remote branch [git fetch | git pull]\n 14. Garbage collection [git gc]\n 15. Search for a part of code [git grep]\n\n* - Merging two branches can be quite complicated\n\nc) Read modules of the client: (most of this need not be written, just\nneed to be organised)\n\n 1. See the status of repository [git status]\n 2. Show diff of the current working file compared to HEAD [git diff]\n 3. List all the commits with pagination [git log]\n 4. With every commit we can\n * Visualise trees [git ls-tree]\n * Visualise files and diffs [git show]\n * Visualise annotations [git blame]\n 5. List all branches including remote ones [git branch]\n 6. Search commits, branches, authors etc..\n\nd) Usage of the client:\n\nThis client can be used in 2 ways.\n\n* Install a local version using instaweb - The gitweb will be only\naccessible by you. You can browse through the git repository using\nread modules and simultaneously work on them using write modules.\n* Install on intranet - A company when installs this gitweb along with\nsome other login and account managing scripts will be able to order\ntheir employees to login and ask them to work on the code with out the\nsecurity risk of providing ssh access to the git repository host.\n* Install on web - Just like normal gitweb, or enable write modules to\nlook like gist.github.com\n\ne) Future functionalities:\n\n * Implementing a file editor\n * Rebasing branches\n * Content History browser - (The gsoc 2010 idea in wiki)\n * Implementing git bisect\n * Cherry picking\n * Patches management along with email\n * Viewing git stats in an interactive user interface\n * Developing API to work with gitweb for storing information in\nform of a git repository\n\nIf completed properly, this is going to be a combination of gitk,\ngit-gui and gitweb, giddy, git-age and other git tools into a great\ncode. Many of the current git users are dissatisfied with current git\nclients and have always been complaining about them in the IRC. Also\nsome of them complain about the complexity of installation of gitweb.\nThis project will solve both the problems.\n\nI will try to make sure that the patches to be as small as possible\nand easily reviewable. Also my vacation starts on May 2nd and ends on\nAugust 1st. So most of the project work will be done during the start\nof the GSoC project rather than in the end.\n\nf) Sample Work - Mockup:\n\nA small pre-version smaple of the project can seen in my github\nrepository named 'gittor' here. It is written in python and just a\nsmall sampe of my work in write modules. This client is capable of\nbuilding any other functionality and can integrate the functionalities\nof any other git tools.\n\n\nTimeLine\n\nI strongly believe in Agile methodology and stick to it. Agile\npractices make all the more sense in open source projects like Git,\nwhere the features are added/modified on the basis of the user's\nfeedback. We should have the ability to swiftly modify the product or\nfeature on the basis of the feedback from the community.\n\nThe following gives a brief idea about the iteration cycle that I'll\nbe following during the development period: The iteration cycle is of\n1 day duration\n\n * Discuss the deliverables for the next iteration with the mentors\nalong with my daily report.\n * Work on the implementation and send patches on implemented\nfunctionality in email to developers mailing list.\n * The developers and the mentors review it and try to merge it upstream\n * Fix bugs, tweak UI etc depending on the feedback. Also document\neverything while its still fresh in my mind.\n\n[Prior May 24]\nRead and understand the code of current gitweb. Install it and play with it.\n\n[May 4th week - June 1st week]\nSplit the whole code of gitweb into framework structure and setup\nlibrary files along with installation and configuration.\n\n[June 2nd week]\nMove the read modules accordingly\n\n[June 3rd week]\nComplete module from W1 to W3\n\n[June 4th week]\nComplete modules from W4 to W7\n\n[July 1st week]\nComplete module W8 and W9\n\n[July 2nd week]\nCheck for any possible and potential security loopholes or bugs\n\n[July 3rd week]\nComplete modules W10 and W11\n\n[July 4th week]\nComplete modules W12 and W13\n\n[Aug 1st week]\nComplete mdoules W14 and W15\n\n[Aug 2nd week]\nScrub code, Improve Documentation and last minute touches\n\n-- W means write modules\n\n\nAbout Me\n\nI am an Indian student, doing my Bachelor's Degree in Computer Science\nand Engineering at IIT Madras, one of the top Universities in the\nWorld. I beleive I am a fast learner and have learnt most of the\nfamous programming languages in the coding world. I am 19 years old\nand have a keen interest in field of Game programming.\n\n1. Open Source Experience\n\nOpen Source Experience is one thing which everyone requires if he want\nto participate in Google Summer of Code. We need to have knowledge of\nversion control systems, such as SVN, GIT etc.. . Also they need to\nfollow the standard coding pratices and methods either given by the\nproject members or community. Theys should also be able to communicate\nwell. I believe I have all these mentioned qualities and have a keen\ninterest in field of OpenSource programming.\n\n* LimeSurvey\nLimeSurvey is self-described as the 'leading open source tool for\nonline surveys', which probably isn't much of an exaggeration. I have\nalready submitted many patches for bugs and committed a few changes\nmyself\n\n* Charty - Google Wave Gadget\nIt is a Google Wave gadget for embedding interactive charts and\ngraphs. It uses methods like Google Wave API, XML, JSON and\njavascript. It's source is made open for all.\n\n* BBGFramework\nContributed to the open source PHP5 based Browser Based Gaming\nframework by adding installation package and fixing bugs.\n\n* Hackerz\nIt is an open source Hacking simulation game written in java and\ncurrently in very early stage with short source control history.\n\n2. Coding Expereince\n\nThere are more to my experience in programming than the ones listed in\nabove section. They all are in different languages of programming.\n\n* My Sport Club Manager - Browser Based Game\nIt is browser based Ice hockey simulation game that runs on PHP and\nmysql and uses other web technologies like AJAX and javascript\nlibraries like prototype. Designed a game flow and a database\nstructure and implemented the same. It offers a rich gameplay where\nclubs can be managed with parameters like stadium, tactics, formation,\nfinance, stats etc.. A runtime commentatory is genertated\nencapsulating all important movements of the game simulation.\n\n* Web related works\n Created a PHP based file system Database and Query Language for\nsmall scale database applications.\n Designed and developed a fully valid CSS for wordpress, the\nfamous blogging platform.\n Developed a single page forum script to avoid space issues and\noptimized database calls to reduce the execution time unlike the\ntraditional bulky forums.\n Incorporated a web-based application that offers flexibility in\npresentation of the information to generate a structured resume\nfollowing pre-defined document standards\n\n* Non-web related works\n Designed and implemented an 8 bit micro-processor using Verilog, a HWDL\n Developed an IRC bot for listening and logging a particular\nchannel given the required details.\n Developed an AI for 'Dots and Boxes' game in Java.\n Designed and developed a small TicTacToe Network game server and\nclient in Python\n\n3. Academic Experience\n\nI beleive I am a fast learner and have learnt most of the famous\nprogramming languages in the coding world. Some of the courses which\nare relevant to my GSoC project and proposal are:\n\n * Data Structures and Algortihms\n * Advanced Computer Programming\n * Introduction to Computer Programming\n\nThe other courses which I have taken and non-relevant to the project\nare Languages Machines and Computations, Switching Circuits and Logic\nDesign, Computer Architecture and Organisation.\n\nDifferent Programming languages which I am comfortable with:\n\n * Python\n * PHP\n * SQL\n * Javascript\n * AJAX\n * C\n * C++\n * HTML\n * CSS\n * Java\n * Verilog\n * Assembly language\n\nI believe in taking initiatives and executing them. I have a natural\naptitude for technology as demonstrated by my numerous innovative\nendeavors. I believe I am ambitious, creative and hardworking which\nmakes me an asset for any organization/team.\n\n4. Involvement with Git\n\nI use git for most of my projects and am fascinated by it's speed and\nuasbility. I think it is and is going to be the best content tracker\never known to the world.\n\nI have been subscribed to git mailing list for 2 months and have\nalready put one of my ideas forward to the git developers in the\nthread linked here\n\nI also submitted a patch which advices the users in git status to add\na file to gitignore if he want to ignore it permanently. It can seen\nin this mailing list thread here.\n"},{"id":"139823","messageId":"201004181950.19610.jnareb@gmail.com","threadId":"23468","inReplyTo":"20100418021223.GP10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-18T17:50:17Z","receivedAt":"2010-04-18T17:50:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, Apr 18, 2010, Petr Baudis wrote:\n> On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:\n>> On Sun, Apr 18, Petr Baudis wrote:\n>>> On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:\n \n>>>> Or is it\n>>>> meant as web analogue of git-gui: a committool, with ability to create\n>>>> new commits, perhaps to edit files (and add them, delete them, move them\n>>>> around), a bit like ikiwiki with Git backend, or other Git based wikis\n>>>> and blogs?\n>>> \n>>> Yes. Though it is probably supposed to be real Git frontend with Git\n>>> semantics, not something more abstract with Git under the hood.\n>> \n>> Hmmm... doesn't look so easy. What to do about simultaneous access\n>> (what webmin does?), and working directory (what ikiwiki does?)?\n> \n> I would expect it to work the same as if you work in single working\n> copy from multiple shells. If multiple people want to collaborate, each\n> should have their own clone to begin with.\n\nSo it is intended, I guess, more like git-instaweb or webmin, not like\nadministrative parts of Girocco (or repo.or.cz), GitHub, Gitorious or\nInDefero. Probably authentication and authorization would not be needed\nthen, if it is to be run as web interface but locally...\n \n>> Well, you can always add some of \"Web Client\" functionality directly\n>> to gitweb (for example dispatch must be, I think, in gitweb).\n> \n> But I don't think you can reasonably separate a major portion of web\n> client that would not depend on gitweb functions like href(), format*()\n> etc. all over the map.\n\nWell, there is also copy'n'paste of code as a last resort. \n\nI guess that git-gui and gitk duplicate some of their functionality\n(and only git-gui is split; gitk is monolitic single file, even larger\nthan gitweb: 320KB vs 220KB).\n\n>> Or you\n>> can (ab)use \"do $gitwebgui_pm;\" instead of \"require $gitwebgui_pm;\",\n>> like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3\n>> (second chunk).\n> \n> This already occured to me, yes. It's tempting to have this as the\n> emergency way out, shall other things fail. But .\n ^^^^^^^^^^-- ???\nBut what?\n\nYes, it is not as elegant as \"require\", and you have to catch errors\nin \"do\"-ed file yourself (as described at the end of `perldoc -f do`).\n\n>> OTOH we can always make gitweb \"use Git;\" and move some of its routines,\n>> to it after generalization (e.g. config management using single run of\n>> \"git config -l -z\", unquoting paths, parsing commit/tag/ls-tree/difftree\n>> etc., date parsing and conversion).\n> \n> Yes, but not things like href(), git_header_html() and other absolutely\n> essential routines.\n\nTrue.\n\n>>>> 3. Split Gitweb, add \"Web Client\" as one of modules. Might be best\n>>>> from the purity point of view, but is practical only if it is\n>>>> integrated in gitweb. That would require getting gitweb maintainer\n>>>> out of GSoC. Also I am not sure how feaible this approach would be.\n>>> \n>>> Would it be really required to get gitweb maintainer out of GSoC in\n>>> order to go this way? Why?\n>> \n>> Well, at least someone who would be able to manage integrating split\n>> gitweb. I think that splitting gitweb, and doing it well, is quite\n>> outside this GSoC 2010 proposal: it would be too much. \n> \n> This was my hesitation at the beginning, but I'm not really sure if\n> it's really so hard, _if_ we resist the temptation to snowball unrelated\n> cleanups on top of it. Conceptually, it isn't really hard to do, is it?\n> The only tricky thing would be making sure instaweb still works and\n> installation is still easy, but I don't see anything really difficult in\n> this area either...?\n\nCurrently to install gitweb you have to copy *one* script, and a few\nstatic files (2 x image, CSS, JavaScript). You can configure it using\n\"make gitweb\" with appropriate options, you can simply edit gitweb script,\nor you can leave this to the gitweb config file.\n\nThere are quite a few requirements that gitweb should fulfill:\n* It must be able to install without admin rights, and requirng to\n install Perl modules system wide. We can rely on core Perl modules,\n on git core and possibly on perl-Git being installed.\n* It must be able to install without editing web server config file,\n nor setting environment variables for the user account that is used\n by the web server (e.g. 'apache', or 'web', or 'nobody').\n* Possibly also it should be easy to install gitweb \"by hand\", without\n requirng to use build system.\n* Any automatic installation target must take into account that gitweb\n must run on many web servers (Apache as CGI, Apache as mod_perl, nginx,\n lighttpd, IIS, Moongose, Webrick,...) and on many distributions and\n operating systems (where location of server, and server configuration\n might differ). But I guess we can borrow some code from git-instaweb.sh\n\n\nAlso there is a question _how_ to split gitweb into modules, \ne.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should\nbe split. But I guess any splitting would suffice; we need to provide\na way to build and install split gitweb. \n\nSplit can be as simple as:\n\n Makefile, or Makefile.PL, or Build.PL\n gitweb.perl\n static/git-logo.png\n static/git-favicon.png\n static/gitweb.css\n static/gitweb.js\n lib/Gitweb/Utils.pm (Gitweb::Utils)\n lib/Gitweb/Editor.pm (Gitweb::Editor, for GSoC2010, if it gets accepted)\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139841","messageId":"20100418195623.GA3563@machine.or.cz","threadId":"23468","inReplyTo":"201004181950.19610.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-18T19:56:23Z","receivedAt":"2010-04-18T19:56:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Apr 18, 2010 at 07:50:17PM +0200, Jakub Narebski wrote:\n> So it is intended, I guess, more like git-instaweb or webmin, not like\n> administrative parts of Girocco (or repo.or.cz), GitHub, Gitorious or\n> InDefero. Probably authentication and authorization would not be needed\n> then, if it is to be run as web interface but locally...\n\nIf the project is a success, I wanted to use it for mob branch editing\non repo.or.cz. It could also be used as open-source Gist alternative.\nBut it needs to be coded so that it does not require an actual checked\nout copy (which shouldn't be too much hassle).\n\n> >> Well, you can always add some of \"Web Client\" functionality directly\n> >> to gitweb (for example dispatch must be, I think, in gitweb).\n> > \n> > But I don't think you can reasonably separate a major portion of web\n> > client that would not depend on gitweb functions like href(), format*()\n> > etc. all over the map.\n> \n> Well, there is also copy'n'paste of code as a last resort. \n\nI would prefer the do. :-)\n\n> >> Or you\n> >> can (ab)use \"do $gitwebgui_pm;\" instead of \"require $gitwebgui_pm;\",\n> >> like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3\n> >> (second chunk).\n> > \n> > This already occured to me, yes. It's tempting to have this as the\n> > emergency way out, shall other things fail. But .\n> ^^^^^^^^^^-- ???\n> But what?\n> \n> Yes, it is not as elegant as \"require\", and you have to catch errors\n> in \"do\"-ed file yourself (as described at the end of `perldoc -f do`).\n\nOops, sorry. I meant that it should be really only last result if we try\nto split things and for some reason it keeps not working out.\n\n> Currently to install gitweb you have to copy *one* script, and a few\n> static files (2 x image, CSS, JavaScript). You can configure it using\n> \"make gitweb\" with appropriate options, you can simply edit gitweb script,\n> or you can leave this to the gitweb config file.\n\nI don't really think things can get *any* more complicated than \"also\ncopy over this directory recursively\", do they?\n\n> Also there is a question _how_ to split gitweb into modules, \n> e.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should\n> be split. But I guess any splitting would suffice; we need to provide\n> a way to build and install split gitweb. \n> \n> Split can be as simple as:\n> \n> Makefile, or Makefile.PL, or Build.PL\n> gitweb.perl\n> static/git-logo.png\n> static/git-favicon.png\n> static/gitweb.css\n> static/gitweb.js\n> lib/Gitweb/Utils.pm (Gitweb::Utils)\n> lib/Gitweb/Editor.pm (Gitweb::Editor, for GSoC2010, if it gets accepted)\n\nExactly! I think we can do this reasonably incrementally; if something\nis not working out, we can move it again later. Let's not overengineer\nstuff. I think it would make sense to just split out something like\nGitweb::Git (for Git invocations), Gitweb::CGI (for CGI parsing and\nHTML output toolkit) and perhaps Gitweb::Util for misc. stuff. Then,\nif we feel like it, maybe we can start splitting out things more, like\nGitweb::CGI::Blame, but I don't think that's even neccessary for now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139850","messageId":"201004182323.02311.jnareb@gmail.com","threadId":"23468","inReplyTo":"n2le72faaa81004180152pb84cef2cn2a7eb95da64420b1@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-18T21:22:58Z","receivedAt":"2010-04-18T21:22:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:\n\n> Here is my rewritten proposal as Christian and Petr asked me to write.\n> Please go through this.\n\nThanks for sending this to git mailing list for review.\n\n> =====================================================\n> \n> Splitting gitweb and developing write functionalites\n> Student: Pavan Kumar Sunkara\n> \n> This project aims at splitting and organising the 6800 lines code of\n> gitweb.pl into a nicely structured set of files. Not only providing\n> the browsing functionalities in gitweb, but it also aims at developing\n> functionalities for working on a git repository.\n\nFirst, a question: do you feel proficient enough in Perl (and in web\nscripting in Perl), or do you prefer other programming language for\nweb, like e.g. Python? If you feel like you would do better programming\nin Python (or PHP, or Ruby) rather than in Perl, you could write the\nmain part of this GSoC project in said language, and provide only hooks\ninto gitweb (with the help of developers on git mailing list).\n\nSecond, it would probably be not \"splitting ... into ... a set of \nfiles\", but rather \"splitting gitweb into modules\" (see e.g. \nWeb::Simple, SVN::Web, etc). \n\nI don't understand \"providing the browsing functionalities in gitweb\":\ngitweb *has* browsing functionalities. The whole idea of integrating\nyour \"Web CLient\" with gitweb was to avoid duplicating repository \nbrowsing and vieweing functionality, and to concentrate on the \"edit\" \npart.\n\n\"It aims at developing functionalities for working on a git repository.\"\nNot only this is not grammatical, but also doesn't tell us the goal\nof your project. Is it something to edit files and create commits via\nweb, be to git-gui what git-instaweb is to gitk? Is it about editing\ngitweb-specific configuration, like README/README.html and 'description' \nfile from web browser? Is it managing git repositories, i.e. create, \nfork or clone and mirror repositories, something that Gerrit does for\nrepo.or.cz (repo.or.cz uses gitweb for viewing repositories)?\n\n> \n> First I will describe my project goals, giving an overview of what I\n> would like to contribute to git. Second I will give the proposed time\n> line of the project which includes all the information about the\n> project. Lastly I will give some information about myself.\n\nThis paragraph is in my opinion a bit unnecessary. It would be useful\nif it was 50+ pages book, or even 10+ pages article.\n \n> \n> Project Goals\n> \n> 1. What is the goal of your project?\n>\n> The project goal is to try and implement write functionalities into\n\nWhat are those \"write functionalities\"? There are many different \nfeatures that can be described as \"write functionalities\": what exactly \ndo you want to do? This description is a bit too generic.\n\n> gitweb along with it's browsing functionalities.\n\nYou probably meant here \"into gitweb to go along with its browsing\ncapabilities\".\n\n> It also aims at splitting and organising the structure of gitweb\n> perl script. \n\nGrammar. \"Another goal is to split gitweb Perl script and reorganize \nits structure\".\n\n> \n> I would like to split the gitweb script in such a way that, in the\n> future others will be able to develop more functionalities for gitweb\n> (let it be 'read' or 'write' actions) with the help of the framework\n> like structure of the new gitweb.\n\nO.K.\n\nOne of the goals for splitting gitweb is, I think, making it easier to \nmanage gitweb codebase, i.e making it easier to contribute to gitweb,\nand to add extra features to it.\n\n> \n> * 'read' means browsing through the code and repository\n> * 'write' means working on the code and repository.\n\nThis doesn't tell us much.\n\n> \n> 2.How would you measure its success or failure?\n>\n> There are two parameters which would majorly determine the success or\n> failure of the project.\n> \n> * Splitting gitweb such that there should be no problem with the\n> installation of gitweb across cross servers and cross systems.\n\nThat is a good idea: the requirement that installing gitweb should\nbe easy after splitting it, and it should work for many different\nweb servers, and across different systems. Perhaps it would be good\nidea to add that we want to be able to install gitweb as non root.\n\n> * It should be possible that the new gitweb requires less time to\n> work on a git repository than any other git client.\n\nI don't understand this sentence. Could you rephrase this goal?\nDid you wanted to say here that working with new addition to gitweb\nwould be as easy as working with other git GUIs (git commit tools)?\n\n> * User friendly graphical interface with smart UI design when\n> compared to any other git clients or browsers.\n\nThis is rather vague for a goal. Do you want to be able to edit\nfiles and commit them? To add new files and remove tracked files\n(or just untrack them)? To cherry-pick, revert, amend commit?\nTo switch between branches and reqwind a branch? To run and visualize\ngit-bisect? To merge branches and resolve merge conflicts? To rebase\nand resolve rebase conflicts?\n\n> \n> 3.Describe your project in more detail.\n>\n> I would like to split the currently 6800 long piece of code in\n> gitweb.pl perl script into small files which will result in better\n> readability, maintainability and modifiability. The file structure of\n> the new gitweb is given below and I will explain the working after it.\n\nO.K. this describes the new goal: splitting gitweb to make it easier to\nadd new features, like the example \"write\" feature.\n\n> \n> (From now on, I would like to call the actions of gitweb as modules of \ngitweb)\n> \n> a) File Structure:\n> \n> * gitweb.pl -- Main script parsing urls and calling required\n> modules\n\nO.K. This would be the main application: the one responsible for \ndispatch (and perhaps parsing command line options, like git-instaweb).\n\n> * gitweb.tpl -- The template of the web page (GUI) in which\n> modules are embedded\n\nErrrr... what? Gitweb currently does not use templating engine.\nThere are no templating engines in Perl core, writing yet another one\nonly for gitweb would be stupid, and choosing one would I guess result\nin bikeshedding spanning whole summer and then some (which one to\nchoose: Template Toolkit with its domain specific language, Haml-like \nperlish templates of Template::Declare and Markapl, or pure (X)HTML\ntemplates of Template::Semantic and HTML::Zoom?).\n\nOr did you mean lib/Gitweb/View/Default.pm - the view part of MVC \nmodel, containing subroutines responsible for the look of gitweb?\n\n> * gitweb.css -- The style for the gitweb pages.\n> * gitweb.js -- javascript to make gitweb more interactive\n\nYou forgot other static files: git-logo.png and git-favicon.png.\n\nYou also forgot the build system: Makefile, or Makefile.PL (if gitweb\nis to use ExtUtils::MakeMaker like Git.pm does), or Build.PL (if\ngitweb is to use Module::Build instead). The very important part.\n\n> * modules (dir) -- directory containing the write and read modules.\n> * lib (dir) -- some basic files like config, error_handler,\n> templater, redirecter, htmlHelper etc..\n\nI'm not sure about modules/ directory: wouldn't lib/ be enough?\nWhat needs to be in modules/ that cannot be put in lib/?\n\nAlso you wouldn't want to split gitweb into files each containing single\nsubroutine, but in packages such like Gitweb::Utils, Gitweb::Repo,\nGitweb::Action::ProjectsList (this is only a proposal).\n\n> \n> The current gitweb makefile makes a gitweb.cgi from the perl script\n> and requires apache or lighttpd server for it's working.\n\nErrr... gitweb Makefile does not require Apache or lighttpd server\n(that is what you sentence seems to imply). \n\nWhat is more, gitweb requires to run any web server that supports CGI \n(including but *not limited to* Apache, lighttpd, nginx,...) or Apache \nwith mod_perl (via ModPerl::Registry handler). It s not limited to\nApache or lighttpd.\n\n> I would like \n> to continue this process but the change will be in the gitweb perl\n> script.\n\nI don't quite understand this sentence. What would be the build \nprocedure for new gitweb + \"Web Client\", and how such new gitweb (with \nor without \"Web Client\" can be installed, optionally how such new \ngitweb with \"Web Client\" can be run (like git-instaweb.sh)?\n\n> The new script includes config and other basic files, checks \n> the URL, parses it, detects the module, manage session and includes\n> the proper module.\n\nO.K., so after splitting the main gitweb.perl file (from which \ngitweb.cgi would be created during build) includes configuration\n(hmmm... shouldn't default configuration and perhaps reading \nsite-specific configuration too be put into separate Perl module?),\ndispatch (checking and parsing URL, verifying parameters, and\nchoosing action to run), and checking which extra modules (and\ntherefore which actions) are available.\n\n\"Manage session\"... err, current gitweb does not need session \nmanagement. Would the \"write\" module require it, even if we can assume \nthat you are the only client like with git-instaweb, and authentication \nis not required? I would also recommend to not reinwent the wheel,\nand if you feel that \"write\" module really needs session management,\nuse some existing CPAN module for it like e.g. CGI::Session, or at least \nborrow (some) code from it.\n\n> It then retreives the output of the module and \n> substitutes it with the gitweb.tpl template file string and gives out\n> a proper HTML, CSS web page.\n\nAs I said gitweb currently do not use templating engine. Currently \nsubroutines that render gitweb actions use git_header_html and \ngit_footer_html and similar subroutines... if needed.\n\nSidenote: I'd prefer that gitweb do not loose ability to stream its \nresponse, at least for some actions like 'blob_plain', 'patches', and \nwhat's most important for performance reasons 'snapshot' view.\n\n> It also contains some basic library files \n> in the lib directory.\n\nThe new split gitweb, or the new gitweb.perl script? It is not clear \nwhat \"it\" refers to here. What does \"some basic library files\" means?\nIf you want for functional groups of subroutines from gitweb to be split \ninto separate files/modules, like Gitweb::Utils with href() etc, like \nGitweb::Repo with parse_commit and similar, please say it explicitely.\n\n> The new gitweb uses session variables to track \n> some of the variables rather than including them in the url.\n\nWhy? If it is possible and feasible to be sessionless, then it is \nbetter to do so. Session state consumes resources on the server.\nHTTP protocol is naturally stateless.\n\n> The write \n> modules need not be working in a gitweb installation like repo.or.cz,\n> so we will also have an option to disable the write modules.\n\nThat is a good idea: if \"write\" module is not installed, its features \nare not available.\n\n> \n> b) Write modules of the client:\n> \n> 1. Add existing repositories to the gitweb -- This will list the\n> given repo into gitweb config\n\nNote that if gitweb scans for repositories ($projects_list is\na directory, not a file with the list of projects), gitweb would detect \nnew repository automatically. This feature (autodetecting \nrepositories) is fore example requirement on git.kernel.org.\n\n> 2. Create new/Clone repositories into a given path [git init |\n> git clone] -- This will create new repo and list it\n\n\"Create new repository\" and \"fork it\", like Girocco does for \nrepo.or.cz...\n\n> 3. Add/Remove/Move files [git add | git rm | git mv]\n> 4. Stage/Unstage files [git add | git reset]\n> 5. Add files to ignore list when you click on 'Ignore' link\n\nAll the above require ability to display a state of a working directory, \ni.e. something like 'tree' view but for working area of repository (or \nthe index) rather than taken from some commit.\n\n> 6. Discard changes to a file in working copy [git reset]\n\nO.K.\n\n> 7. Commit to the repository with a log message and an optional\n> sign-off [git commit]\n\nYou would probably want also to display status of the files in the \nworking directory (this goes along with 'tree' view for files in \nworking area: we would probably want to display state for those files),\nand to display diff between current HEAD and working area. Gitweb can \ndisplay commitdiff for a given commit, and (what is less known) diff \nbetween two arbitrary commits only.\n\n> 8. Switch branches [git branch]\n\nYou would probably want creating new branches here, too.\n\n> 9. A simple branch merging* [git merge]\n\nDo you mean here by \"simple\" merge that does not lead to merge \nconflicts?\n\n> 10. Creating tags [git tag]\n\nO.K. Does it include creating signed tags?\n\n> 11. Checkout code to a specific commit or branch or tag\n> [git checkout] \n\nNote that \"git checkout \" is switching branches.\n\n> 12. Push to a remote branch [git push]\n> 13. Fetch/Pull from a remote branch [git fetch | git pull]\n\nYo would need support for either editing config, or for interface to \n[git remote add] first, otherwise the only remote available would be \n'origin'. Unless you are interested in pushing to / fetching from\nrepository given by URL...\n\n> 14. Garbage collection [git gc]\n\nYou would probably want to be able to gather statistics, a la\n[git count-objects -v].\n\n> 15. Search for a part of code [git grep]\n\nNote that current gitweb includes some support for 'grep' search,\nbut obviously you can only search repository (some specified commit),\nnot index nor working area.\n\n> \n> * - Merging two branches can be quite complicated\n> \n> c) Read modules of the client: (most of this need not be written, just\n> need to be organised)\n> \n> 1. See the status of repository [git status]\n\nNew, needed for commit.\n\n> 2. Show diff of the current working file compared to HEAD [git diff]\n\nNew, needed for commit.\n\n> 3. List all the commits with pagination [git log]\n\nExists in gitweb.\n\n> 4. With every commit we can\n> * Visualise trees [git ls-tree]\n> * Visualise files and diffs [git show]\n> * Visualise annotations [git blame]\n\nAll those exists already in gitweb.\n\n> 5. List all branches including remote ones [git branch]\n\nRemote tracking branches are not currently supported, but gitweb can \ndisplay local branches and tags.\n\n> 6. Search commits, branches, authors etc..\n\nExists in gitweb.\n\n> \n> d) Usage of the client:\n> \n> This client can be used in 2 ways.\n> \n> * Install a local version using instaweb - The gitweb will be only\n> accessible by you. You can browse through the git repository using\n> read modules and simultaneously work on them using write modules.\n\nThis part could be doeable dusing GSoC 2010 (if this project gets \naccepted), I think.\n\n> * Install on intranet - A company when installs this gitweb along with\n> some other login and account managing scripts will be able to order\n> their employees to login and ask them to work on the code with out the\n> security risk of providing ssh access to the git repository host.\n> * Install on web - Just like normal gitweb, or enable write modules to\n> look like gist.github.com\n\nThis would require authentication support, which I think might be too \nmuch for GSoC.\n\n> e) Future functionalities:\n> \n> * Implementing a file editor\n\nO.K., although without at least being able to edit file in textarea,\nor to upload new version of a file you would need something outside\n\"write\" module to create new commits anyway.\n\n> * Rebasing branches\n> * Content History browser - (The gsoc 2010 idea in wiki)\n> * Implementing git bisect\n> * Cherry picking\n> * Patches management along with email\n\nO.K.\n\n> * Viewing git stats in an interactive user interface\n\nO.K.\n\n> * Developing API to work with gitweb for storing information in\n> form of a git repository\n\nWhat you mean by that?\n\n[...]\n> f) Sample Work - Mockup:\n> \n> A small pre-version smaple of the project can seen in my github\n> repository named 'gittor' here. It is written in python and just a\n> small sampe of my work in write modules. This client is capable of\n> building any other functionality and can integrate the functionalities\n> of any other git tools.\n\nThat is very good... but see the question at the beginning of my email.\n\n> TimeLine\n\n[...]\n> [June 3rd week]\n> Complete module from W1 to W3\n\nDon't forget to write automated tests, if it is possible.\n\nAlso, W1 to W3 do not tell me much here.\n\n> 3. Academic Experience\n> \n> I beleive I am a fast learner and have learnt most of the famous\n> programming languages in the coding world. Some of the courses which\n> are relevant to my GSoC project and proposal are:\n> \n> * Data Structures and Algortihms\n> * Advanced Computer Programming\n> * Introduction to Computer Programming\n> \n> The other courses which I have taken and non-relevant to the project\n> are Languages Machines and Computations, Switching Circuits and Logic\n> Design, Computer Architecture and Organisation.\n> \n> Different Programming languages which I am comfortable with:\n> \n> * Python\n> * PHP\n> * SQL\n> * Javascript\n> * AJAX\n> * C\n> * C++\n> * HTML\n> * CSS\n> * Java\n> * Verilog\n> * Assembly language\n\nUnfortunately Perl (the language gitweb is written in) is missing...\nSee also first question in this email of mind.\n\nAJAX is not programming language: it is technique. (Also neither\nHTML nor CSS are *programming* languages in strict sense, but that\nis just nitpicking...).\n\n[...]\n> 4. Involvement with Git\n> \n> I use git for most of my projects and am fascinated by it's speed and\n> uasbility. I think it is and is going to be the best content tracker\n> ever known to the world.\n> \n> I have been subscribed to git mailing list for 2 months and have\n> already put one of my ideas forward to the git developers in the\n> thread linked here\n> \n> I also submitted a patch which advices the users in git status to add\n> a file to gitignore if he want to ignore it permanently. It can seen\n> in this mailing list thread here.\n\nGood.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139853","messageId":"20100418223120.GB3563@machine.or.cz","threadId":"23468","inReplyTo":"n2le72faaa81004180152pb84cef2cn2a7eb95da64420b1@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-18T22:31:21Z","receivedAt":"2010-04-18T22:31:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Thanks for work on the proposal!\n\nOn Sun, Apr 18, 2010 at 02:22:20PM +0530, Pavan Kumar Sunkara wrote:\n> 2.How would you measure its success or failure?\n> There are two parameters which would majorly determine the success or\n> failure of the project.\n> \n> * Splitting gitweb such that there should be no problem with the\n> installation of gitweb across cross servers and cross systems.\n\nI believe an important factor in the success of the project is getting\nthese changes merged upstream in the main Git branch.\n\nIf the rest of the project features is not merged (and it *won't* be for\nthe lack of trying), it will still be reasonably easy to use it as a\nthird-party modification. However, if the split-up itself will not be\nmerged, that will have big impact on the usefulness of the whole project\n- so I consider this fairly crucial, please don't under-estimate this\npart, getting things merged can take as much work as doing initial\nimplementation of the stuff! You should plan to submit these patches\nquite early.\n\n> * It should be possible that the new gitweb requires less time to\n> work on a git repository than any other git client.\n\nI'm sorry, I don't understand this.\n\n> 3.Describe your project in more detail.\n> I would like to split the currently 6800 long piece of code in\n> gitweb.pl perl script into small files which will result in better\n> readability, maintainability and modifiability. The file structure of\n> the new gitweb is given below and I will explain the working after it.\n> \n> (From now on, I would like to call the actions of gitweb as modules of gitweb)\n> \n> a) File Structure:\n> \n> * gitweb.pl -- Main script parsing urls and calling required modules\n> * gitweb.tpl -- The template of the web page (GUI) in which\n> modules are embedded\n> * gitweb.css -- The style for the gitweb pages.\n> * gitweb.js -- javascript to make gitweb more interactive\n> * modules (dir) -- directory containing the write and read modules.\n> * lib (dir) -- some basic files like config, error_handler,\n> templater, redirecter, htmlHelper etc..\n> \n> The current gitweb makefile makes a gitweb.cgi from the perl script\n> and requires apache or lighttpd server for it's working. I would like\n> to continue this process but the change will be in the gitweb perl\n> script. The new script includes config and other basic files, checks\n> the URL, parses it, detects the module, manage session and includes\n> the proper module. It then retreives the output of the module and\n> substitutes it with the gitweb.tpl template file string and gives out\n> a proper HTML, CSS web page. It also contains some basic library files\n> in the lib directory. The new gitweb uses session variables to track\n> some of the variables rather than including them in the url. The write\n> modules need not be working in a gitweb installation like repo.or.cz,\n> so we will also have an option to disable the write modules.\n\nFrankly, I'm not very excited from this. First, I recommend that you\ncompletely separate splitting of gitweb to smaller pieces (without any\nmajor conceptual changes) both in the proposal and in actual\nsubmissions.\n\nSecond, you should justify the introduction of session management and\ntemplating. What is the point and why is it neccessary for your project\ngoals?\n\n> b) Write modules of the client:\n> \n> 1. Add Existing repositories to the gitweb -- This will list the\n> given repo into gitweb config\n> 2. Create new/Clone repositories into a given path [git init | git\n> clone] -- This will create new repo and list it\n> 3. Add/Remove/Move files [git add | git rm | git mv]\n> 4. Stage/Unstage files [git add | git reset]\n> 5. Add files to ignore list when u click on 'Ignore' link\n> 6. Discard changes to a file in working copy [git reset]\n> 7. Commit to the repository with a log message and an optional\n> sign-off [git commit]\n> 8. Switch branches [git branch]\n> 9. A simple branch merging* [git merge]\n> 10. Creating tags [git tag]\n> 11. Checkout code to a specific commit or branch or tag [git checkout]\n> 12. Push to a remote branch [git push]\n> 13. Fetch/Pull from a remote branch [git fetch | git pull]\n> 14. Garbage collection [git gc]\n\nSounds reasonable. What am I missing is a way to edit files through the\nweb interface. Also, please spec in more detail the difference between\n[8] and [11].\n\n> 15. Search for a part of code [git grep]\n\nThis is already supported by gitweb. And it's not a \"write\" operation.\n;-)\n\n> c) Read modules of the client: (most of this need not be written, just\n> need to be organised)\n> \n> 1. See the status of repository [git status]\n\nHow will you integrate this with the existing 'tree' action?\n\n> 3. List all the commits with pagination [git log]\n\nWhy?\n\n> 4. With every commit we can\n> * Visualise trees [git ls-tree]\n> * Visualise files and diffs [git show]\n> * Visualise annotations [git blame]\n> 5. List all branches including remote ones [git branch]\n> 6. Search commits, branches, authors etc..\n\nI.e. what we already do?\n\n> d) Usage of the client:\n> * Install on intranet - A company when installs this gitweb along with\n> some other login and account managing scripts will be able to order\n> their employees to login and ask them to work on the code with out the\n> security risk of providing ssh access to the git repository host.\n\nFrankly, the net security risk of providing git-shell access is probably\nlower than using a web interface. ;-) However, I still see this making\nmany corporate people happy and opening doors to less canonical Git\nusecases - it also enables \"zero config\" ability to contribute to Git\nprojects, desirable for less technical users (artists etc.).\n\n> I will try to make sure that the patches to be as small as possible\n> and easily reviewable. Also my vacation starts on May 2nd and ends on\n> August 1st. So most of the project work will be done during the start\n> of the GSoC project rather than in the end.\n\nGreat!\n\n> [May 4th week - June 1st week]\n> Split the whole code of gitweb into framework structure and setup\n> library files along with installation and configuration.\n\nI think this might end up being rather tricky, and would appreciate you\ndetailing this out a bit more, including some expected dates for initial\npatch submissions.\n\n> [July 2nd week]\n> Check for any possible and potential security loopholes or bugs\n\nI appreciate that you are thinking about this, though I'm less sure if\nthis can be efficiently done as a batch job like this.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139866","messageId":"q2se72faaa81004182335r29505960lcc956e981673de7@mail.gmail.com","threadId":"23468","inReplyTo":"w2pe72faaa81004182334xd6fc56d7o31420ca4af867cc2@mail.gmail.com","subject":"GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T06:35:54Z","receivedAt":"2010-04-19T06:35:54Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski wrote:\n>\n> On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:\n>\n> > Here is my rewritten proposal as Christian and Petr asked me to write.\n> > Please go through this.\n>\n> Thanks for sending this to git mailing list for review.\n>\n> > =====================================================\n> >\n> > Splitting gitweb and developing write functionalites\n> > Student:        Pavan Kumar Sunkara\n> >\n> > This project aims at splitting and organising the 6800 lines code of\n> > gitweb.pl into a nicely structured set of files. Not only providing\n> > the browsing functionalities in gitweb, but it also aims at developing\n> > functionalities for working on a git repository.\n>\n> First, a question: do you feel proficient enough in Perl (and in web\n> scripting in Perl), or do you prefer other programming language for\n> web, like e.g. Python?  If you feel like you would do better programming\n> in Python (or PHP, or Ruby) rather than in Perl, you could write the\n> main part of this GSoC project in said language, and provide only hooks\n> into gitweb (with the help of developers on git mailing list).\n>\n\nI don't know perl but learning it an d becoming proficient in it won't\nbe a matter for me. I believe I am a fast learner and I am a computer\nscience student in the top university of India. I learnt python in an\nhour and became proficient in it by a week. So learning perl won't be\na matter for me.\n\n>\n> Second, it would probably be not \"splitting ... into ... a set of\n> files\", but rather \"splitting gitweb into modules\" (see e.g.\n> Web::Simple, SVN::Web, etc).\n>\n\nI would like to take the majority opinion on how to split gitweb.\n\n>\n> I don't understand \"providing the browsing functionalities in gitweb\":\n> gitweb *has* browsing functionalities.  The whole idea of integrating\n> your \"Web CLient\" with gitweb was to avoid duplicating repository\n> browsing and vieweing functionality, and to concentrate on the \"edit\"\n> part.\n>\n\nIt's an error with my grammar. I actually mean to concentrate on \"edit\" part.\nI am not a native english speaker. So, there might be problems with my grammar.\n\n>\n> \"It aims at developing functionalities for working on a git repository.\"\n> Not only this is not grammatical, but also doesn't tell us the goal\n> of your project.  Is it something to edit files and create commits via\n> web, be to git-gui what git-instaweb is to gitk?  Is it about editing\n> gitweb-specific configuration, like README/README.html and 'description'\n> file from web browser?  Is it managing git repositories, i.e. create,\n> fork or clone and mirror repositories, something that Gerrit does for\n> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?\n>\n\nI think you understood it from the later part of my proposal.\n\n>\n> >\n> > First I will describe my project goals, giving an overview of what I\n> > would like to contribute to git. Second I will give the proposed time\n> > line of the project which includes all the information about the\n> > project. Lastly I will give some information about myself.\n>\n> This paragraph is in my opinion a bit unnecessary.  It would be useful\n> if it was 50+ pages book, or even 10+ pages article.\n\nYeah, you are right but I would like to give some introduction.\n\n>\n> >\n> > Project Goals\n> >\n> > 1. What is the goal of your project?\n> >\n> > The project goal is to try and implement write functionalities into\n>\n> What are those \"write functionalities\"?  There are many different\n> features that can be described as \"write functionalities\": what exactly\n> do you want to do?  This description is a bit too generic.\n>\n> > gitweb along with it's browsing functionalities.\n>\n> You probably meant here \"into gitweb to go along with its browsing\n> capabilities\".\n\nYes.\n\n>\n> > It also aims at splitting and organising the structure of gitweb\n> > perl script.\n>\n> Grammar.  \"Another goal is to split gitweb Perl script and reorganize\n> its structure\".\n>\n\nSorry again. As I said, I am not very good in english. I can just communicate.\n\n>\n> >\n> > I would like to split the gitweb script in such a way that, in the\n> > future others will be able to develop more functionalities for gitweb\n> > (let it be 'read' or 'write' actions) with the help of the framework\n> > like structure of the new gitweb.\n>\n> O.K.\n>\n> One of the goals for splitting gitweb is, I think, making it easier to\n> manage gitweb codebase, i.e  making it easier to contribute to gitweb,\n> and to add extra features to it.\n>\n\nYeah.\n\n>\n> >\n> > * 'read' means browsing through the code and repository\n> > * 'write' means working on the code and repository.\n>\n> This doesn't tell us much.\n>\n> >\n> > 2.How would you measure its success or failure?\n> >\n> > There are two parameters which would majorly determine the success or\n> > failure of the project.\n> >\n> >    * Splitting gitweb such that there should be no problem with the\n> > installation of gitweb across cross servers and cross systems.\n>\n> That is a good idea: the requirement that installing gitweb should\n> be easy after splitting it, and it should work for many different\n> web servers, and across different systems.  Perhaps it would be good\n> idea to add that we want to be able to install gitweb as non root.\n>\n> >    * It should be possible that the new gitweb requires less time to\n> > work on a git repository than any other git client.\n>\n> I don't understand this sentence.  Could you rephrase this goal?\n> Did you wanted to say here that working with new addition to gitweb\n> would be as easy as working with other git GUIs (git commit tools)?\n\nyes. I mean it.\n\n>\n> >    * User friendly graphical interface with smart UI design when\n> > compared to any other git clients or browsers.\n>\n> This is rather vague for a goal.  Do you want to be able to edit\n> files and commit them?  To add new files and remove tracked files\n> (or just untrack them)?  To cherry-pick, revert, amend commit?\n> To switch between branches and reqwind a branch?  To run and visualize\n> git-bisect?  To merge branches and resolve merge conflicts?  To rebase\n> and resolve rebase conflicts?\n\nYes, exactly. I think you haven't read the whole proposal before\nwriting this. :-)\n\n>\n> >\n> > 3.Describe your project in more detail.\n> >\n> > I would like to split the currently 6800 long piece of code in\n> > gitweb.pl perl script into small files which will result in better\n> > readability, maintainability and modifiability. The file structure of\n> > the new gitweb is given below and I will explain the working after it.\n>\n> O.K. this describes the new goal: splitting gitweb to make it easier to\n> add new features, like the example \"write\" feature.\n>\n> >\n> > (From now on, I would like to call the actions of gitweb as modules of\n> gitweb)\n> >\n> > a) File Structure:\n> >\n> >    * gitweb.pl -- Main script parsing urls and calling required\n> >      modules\n>\n> O.K.  This would be the main application: the one responsible for\n> dispatch (and perhaps parsing command line options, like git-instaweb).\n>\n> >    * gitweb.tpl -- The template of the web page (GUI) in which\n> >      modules are embedded\n>\n> Errrr... what?  Gitweb currently does not use templating engine.\n> There are no templating engines in Perl core, writing yet another one\n> only for gitweb would be stupid, and choosing one would I guess result\n> in bikeshedding spanning whole summer and then some (which one to\n> choose: Template Toolkit with its domain specific language,  Haml-like\n> perlish templates of Template::Declare and Markapl, or pure (X)HTML\n> templates of Template::Semantic and HTML::Zoom?).\n>\n> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC\n> model, containing subroutines responsible for the look of gitweb?\n>\n\nI would like to add a small 50 lines code for templater class which\ndoes string substitution and embed the module output into tpl file.\nThis method reduces the subroutines like git_header_html etc.. A small\nexample of templater class can be found at\nhttp://matetelki.com/blog/?p=71. It isn't exactly the same i use but\nyou get the basic idea. right ?\n\n>\n> >    * gitweb.css -- The style for the gitweb pages.\n> >    * gitweb.js -- javascript to make gitweb more interactive\n>\n> You forgot other static files: git-logo.png and git-favicon.png.\n>\n> You also forgot the build system: Makefile, or Makefile.PL (if gitweb\n> is to use ExtUtils::MakeMaker like Git.pm does), or Build.PL (if\n> gitweb is to use Module::Build instead).  The very important part.\n\nSorry. I forgot to mention them.\n\n>\n> >    * modules (dir) -- directory containing the write and read modules.\n> >    * lib (dir) -- some basic files like config, error_handler,\n> > templater, redirecter, htmlHelper etc..\n>\n> I'm not sure about modules/ directory: wouldn't lib/ be enough?\n> What needs to be in modules/ that cannot be put in lib/?\n>\n> Also you wouldn't want to split gitweb into files each containing single\n> subroutine, but in packages such like Gitweb::Utils, Gitweb::Repo,\n> Gitweb::Action::ProjectsList (this is only a proposal).\n>\n\nAs i said above, I would like to take the majority opinion on how to\nsplit gitweb.\n\n>\n> >\n> > The current gitweb makefile makes a gitweb.cgi from the perl script\n> > and requires apache or lighttpd server for it's working.\n>\n> Errr... gitweb Makefile does not require Apache or lighttpd server\n> (that is what you sentence seems to imply).\n>\n> What is more, gitweb requires to run any web server that supports CGI\n> (including but *not limited to* Apache, lighttpd, nginx,...) or Apache\n> with mod_perl (via ModPerl::Registry handler).  It s not limited to\n> Apache or lighttpd.\n\nSorry for my grammar.\n\n>\n> > I would like\n> > to continue this process but the change will be in the gitweb perl\n> > script.\n>\n> I don't quite understand this sentence.  What would be the build\n> procedure for new gitweb + \"Web Client\", and how such new gitweb (with\n> or without \"Web Client\" can be installed, optionally how such new\n> gitweb with \"Web Client\" can be run (like git-instaweb.sh)?\n>\n\nI would like it to run new gitweb like git-instaweb.sh\n\n>\n> > The new script includes config and other basic files, checks\n> > the URL, parses it, detects the module, manage session and includes\n> > the proper module.\n>\n> O.K., so after splitting the main gitweb.perl file (from which\n> gitweb.cgi would be created during build) includes configuration\n> (hmmm... shouldn't default configuration and perhaps reading\n> site-specific configuration too be put into separate Perl module?),\n> dispatch (checking and parsing URL, verifying parameters, and\n> choosing action to run), and checking which extra modules (and\n> therefore which actions) are available.\n>\n> \"Manage session\"... err, current gitweb does not need session\n> management.  Would the \"write\" module require it, even if we can assume\n> that you are the only client like with git-instaweb, and authentication\n> is not required?  I would also recommend to not reinwent the wheel,\n> and if you feel that \"write\" module really needs session management,\n> use some existing CPAN module for it like e.g. CGI::Session, or at least\n> borrow (some) code from it.\n>\n\nI mean wouldn't using session be good thing to add. It doesn't need to\nuse parameters like project name all the time in the URL.\n\n>\n> > It then retreives the output of the module and\n> > substitutes it with the gitweb.tpl template file string and gives out\n> > a proper HTML, CSS web page.\n>\n> As I said gitweb currently do not use templating engine.  Currently\n> subroutines that render gitweb actions use git_header_html and\n> git_footer_html and similar subroutines... if needed.\n>\n> Sidenote: I'd prefer that gitweb do not loose ability to stream its\n> response, at least for some actions like 'blob_plain', 'patches', and\n> what's most important for performance reasons 'snapshot' view.\n>\n\nIt will be just a string substitution by a small templater class.\n\n>\n> > It also contains some basic library files\n> > in the lib directory.\n>\n> The new split gitweb, or the new gitweb.perl script?  It is not clear\n> what \"it\" refers to here.  What does \"some basic library files\" means?\n> If you want for functional groups of subroutines from gitweb to be split\n> into separate files/modules, like Gitweb::Utils with href() etc, like\n> Gitweb::Repo with parse_commit and similar, please say it explicitely.\n>\n\nThe basic library files like errorhandlers, session manager,\ntemplater, redirecter, Gitweb::Utils and Gitweb::repo etc..\n\n>\n> > The new gitweb uses session variables to track\n> > some of the variables rather than including them in the url.\n>\n> Why?  If it is possible and feasible to be sessionless, then it is\n> better to do so.  Session state consumes resources on the server.\n> HTTP protocol is naturally stateless.\n>\n> > The write\n> > modules need not be working in a gitweb installation like repo.or.cz,\n> > so we will also have an option to disable the write modules.\n>\n> That is a good idea: if \"write\" module is not installed, its features\n> are not available.\n>\n\nThanks.\n\n>\n> >\n> > b) Write modules of the client:\n> >\n> >   1. Add existing repositories to the gitweb -- This will list the\n> >      given repo into gitweb config\n>\n> Note that if gitweb scans for repositories ($projects_list is\n> a directory, not a file with the list of projects), gitweb would detect\n> new repository automatically.  This feature (autodetecting\n> repositories) is fore example requirement on git.kernel.org.\n>\n\nLet us say if there are multiple repositories in multiple paths,\nwouldn't it be good to add a single project. This option will be\navailable along with scanning $projects_root.\n\n>\n> >   2. Create new/Clone repositories into a given path [git init |\n> >     git clone] -- This will create new repo and list it\n>\n> \"Create new repository\" and \"fork it\", like Girocco does for\n> repo.or.cz...\n\nWhen used as a client, it will be cloning from a URL. right ?\n\n>\n> >   3. Add/Remove/Move files [git add | git rm | git mv]\n> >   4. Stage/Unstage files [git add | git reset]\n> >   5. Add files to ignore list when you click on 'Ignore' link\n>\n> All the above require ability to display a state of a working directory,\n> i.e. something like 'tree' view but for working area of repository (or\n> the index) rather than taken from some commit.\n>\n\nAll the above actions will have link from git status view.\n\n>\n> >   6. Discard changes to a file in working copy [git reset]\n>\n> O.K.\n>\n> >   7. Commit to the repository with a log message and an optional\n> >      sign-off [git commit]\n>\n> You would probably want also to display status of the files in the\n> working directory (this goes along with 'tree' view for files in\n> working area: we would probably want to display state for those files),\n> and to display diff between current HEAD and working area.  Gitweb can\n> display commitdiff for a given commit, and (what is less known) diff\n> between two arbitrary commits only.\n\nAs I said above, it will be available to commit from git status view.\n\n>\n> >   8. Switch branches [git branch]\n>\n> You would probably want creating new branches here, too.\n\nYeah, I mean it.\n\n>\n> >   9. A simple branch merging* [git merge]\n>\n> Do you mean here by \"simple\" merge that does not lead to merge\n> conflicts?\n\nIt can lead to merge conflicts but what I mean is you cannot solve it\nfrom the client.\n\n>\n> >  10. Creating tags [git tag]\n>\n> O.K.  Does it include creating signed tags?\n\nYes.\n\n>\n> >  11. Checkout code to a specific commit or branch or tag\n> >      [git checkout]\n>\n> Note that \"git checkout \" is switching branches.\n\nYes. Sorry for repeating it.\n\n>\n> >  12. Push to a remote branch [git push]\n> >  13. Fetch/Pull from a remote branch [git fetch | git pull]\n>\n> Yo would need support for either editing config, or for interface to\n> [git remote add] first, otherwise the only remote available would be\n> 'origin'.  Unless you are interested in pushing to / fetching from\n> repository given by URL...\n>\n\nI think i missed that point. all functionalites with \"git remote\" will\nbe added too.\n\n>\n> >  14. Garbage collection [git gc]\n>\n> You would probably want to be able to gather statistics, a la\n> [git count-objects -v].\n\nNice idea.\n\n>\n> >  15. Search for a part of code [git grep]\n>\n> Note that current gitweb includes some support for 'grep' search,\n> but obviously you can only search repository (some specified commit),\n> not index nor working area.\n>\n\nI want to include this so that in future it can integrated with\npickaxe interface.\n\n>\n> >\n> > * - Merging two branches can be quite complicated\n> >\n> > c) Read modules of the client: (most of this need not be written, just\n> > need to be organised)\n> >\n> >   1. See the status of repository [git status]\n>\n> New, needed for commit.\n>\n> >   2. Show diff of the current working file compared to HEAD [git diff]\n>\n> New, needed for commit.\n>\n> >   3. List all the commits with pagination [git log]\n>\n> Exists in gitweb.\n>\n> >   4. With every commit we can\n> >          * Visualise trees [git ls-tree]\n> >          * Visualise files and diffs [git show]\n> >          * Visualise annotations [git blame]\n>\n> All those exists already in gitweb.\n\nYes. i will just copy the code from the current gitweb.\n\n>\n> >   5. List all branches including remote ones [git branch]\n>\n> Remote tracking branches are not currently supported, but gitweb can\n> display local branches and tags.\n>\n> >   6. Search commits, branches, authors etc..\n>\n> Exists in gitweb.\n>\n> >\n> > d) Usage of the client:\n> >\n> > This client can be used in 2 ways.\n> >\n> > * Install a local version using instaweb - The gitweb will be only\n> > accessible by you. You can browse through the git repository using\n> > read modules and simultaneously work on them using write modules.\n>\n> This part could be doeable dusing GSoC 2010 (if this project gets\n> accepted), I think.\n\nYes. This is the main thing that is needed for a average git user.\n\n>\n> > * Install on intranet - A company when installs this gitweb along with\n> > some other login and account managing scripts will be able to order\n> > their employees to login and ask them to work on the code with out the\n> > security risk of providing ssh access to the git repository host.\n> > * Install on web - Just like normal gitweb, or enable write modules to\n> > look like gist.github.com\n>\n> This would require authentication support, which I think might be too\n> much for GSoC.\n\nYes. I will not be doing it in GSoC and it won't be a part of gitweb,\nBut I hope to provide an authentication wrapper for gitweb in future.\n\n>\n> > e) Future functionalities:\n> >\n> >    * Implementing a file editor\n>\n> O.K., although without at least being able to edit file in textarea,\n> or to upload new version of a file you would need something outside\n> \"write\" module to create new commits anyway.\n>\n> >    * Rebasing branches\n> >    * Content History browser - (The gsoc 2010 idea in wiki)\n> >    * Implementing git bisect\n> >    * Cherry picking\n> >    * Patches management along with email\n>\n> O.K.\n>\n> >    * Viewing git stats in an interactive user interface\n>\n> O.K.\n>\n> >    * Developing API to work with gitweb for storing information in\n> > form of a git repository\n>\n> What you mean by that?\n>\n\nI mean, I will be providing an web API wrapper for gitweb which can be\nused by other web developers to store any information they get into a\ngit repository form and can use it to see the changes they made to the\ninformation step  by step.\n\n>\n> [...]\n> > f) Sample Work - Mockup:\n> >\n> > A small pre-version smaple of the project can seen in my github\n> > repository named 'gittor' here. It is written in python and just a\n> > small sampe of my work in write modules. This client is capable of\n> > building any other functionality and can integrate the functionalities\n> > of any other git tools.\n>\n> That is very good... but see the question at the beginning of my email.\n\nI already answered it. :-)\n\n>\n> > TimeLine\n>\n> [...]\n> > [June 3rd week]\n> > Complete module from W1 to W3\n>\n> Don't forget to write automated tests, if it is possible.\n>\n> Also, W1 to W3 do not tell me much here.\n>\n> > 3. Academic Experience\n> >\n> > I beleive I am a fast learner and have learnt most of the famous\n> > programming languages in the coding world. Some of the courses which\n> > are relevant to my GSoC project and proposal are:\n> >\n> >    * Data Structures and Algortihms\n> >    * Advanced Computer Programming\n> >    * Introduction to Computer Programming\n> >\n> > The other courses which I have taken and non-relevant to the project\n> > are Languages Machines and Computations, Switching Circuits and Logic\n> > Design, Computer Architecture and Organisation.\n> >\n> > Different Programming languages which I am comfortable with:\n> >\n> >    * Python\n> >    * PHP\n> >    * SQL\n> >    * Javascript\n> >    * AJAX\n> >    * C\n> >    * C++\n> >    * HTML\n> >    * CSS\n> >    * Java\n> >    * Verilog\n> >    * Assembly language\n>\n> Unfortunately Perl (the language gitweb is written in) is missing...\n> See also first question in this email of mind.\n>\n> AJAX is not programming language: it is technique.  (Also neither\n> HTML nor CSS are *programming* languages in strict sense, but that\n> is just nitpicking...).\n\nI use this sentence on others and now you are using it on me :-)\nSorry for including them. I thought that they are important for this\nproject so I included the too.\n\n>\n> [...]\n> > 4. Involvement with Git\n> >\n> > I use git for most of my projects and am fascinated by it's speed and\n> > uasbility. I think it is and is going to be the best content tracker\n> > ever known to the world.\n> >\n> > I have been subscribed to git mailing list for 2 months and have\n> > already put one of my ideas forward to the git developers in the\n> > thread linked here\n> >\n> > I also submitted a patch which advices the users in git status to add\n> > a file to gitignore if he want to ignore it permanently. It can seen\n> > in this mailing list thread here.\n>\n> Good.\n>\n> --\n> Jakub Narebski\n> Poland\n\nPlease ask me if you have any other doubts regarding this project.\n"},{"id":"139867","messageId":"u2ve72faaa81004182346zdf4bd0b3m3341717b1555c0a9@mail.gmail.com","threadId":"23468","inReplyTo":"20100418223120.GB3563@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T06:46:31Z","receivedAt":"2010-04-19T06:46:31Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis wrote:\n> Thanks for work on the proposal!\n>\n> On Sun, Apr 18, 2010 at 02:22:20PM +0530, Pavan Kumar Sunkara wrote:\n>> 2.How would you measure its success or failure?\n>> There are two parameters which would majorly determine the success or\n>> failure of the project.\n>>\n>>    * Splitting gitweb such that there should be no problem with the\n>> installation of gitweb across cross servers and cross systems.\n>\n> I believe an important factor in the success of the project is getting\n> these changes merged upstream in the main Git branch.\n>\n> If the rest of the project features is not merged (and it *won't* be for\n> the lack of trying), it will still be reasonably easy to use it as a\n> third-party modification. However, if the split-up itself will not be\n> merged, that will have big impact on the usefulness of the whole project\n> - so I consider this fairly crucial, please don't under-estimate this\n> part, getting things merged can take as much work as doing initial\n> implementation of the stuff! You should plan to submit these patches\n> quite early.\n\nYes, I promise that I will try my best to submit patches early and try\nto get them merged them into mainstream.\n\n>>    * It should be possible that the new gitweb requires less time to\n>> work on a git repository than any other git client.\n>\n> I'm sorry, I don't understand this.\n>\n>> 3.Describe your project in more detail.\n>> I would like to split the currently 6800 long piece of code in\n>> gitweb.pl perl script into small files which will result in better\n>> readability, maintainability and modifiability. The file structure of\n>> the new gitweb is given below and I will explain the working after it.\n>>\n>> (From now on, I would like to call the actions of gitweb as modules of gitweb)\n>>\n>> a) File Structure:\n>>\n>>    * gitweb.pl -- Main script parsing urls and calling required modules\n>>    * gitweb.tpl -- The template of the web page (GUI) in which\n>> modules are embedded\n>>    * gitweb.css -- The style for the gitweb pages.\n>>    * gitweb.js -- javascript to make gitweb more interactive\n>>    * modules (dir) -- directory containing the write and read modules.\n>>    * lib (dir) -- some basic files like config, error_handler,\n>> templater, redirecter, htmlHelper etc..\n>>\n>> The current gitweb makefile makes a gitweb.cgi from the perl script\n>> and requires apache or lighttpd server for it's working. I would like\n>> to continue this process but the change will be in the gitweb perl\n>> script. The new script includes config and other basic files, checks\n>> the URL, parses it, detects the module, manage session and includes\n>> the proper module. It then retreives the output of the module and\n>> substitutes it with the gitweb.tpl template file string and gives out\n>> a proper HTML, CSS web page. It also contains some basic library files\n>> in the lib directory. The new gitweb uses session variables to track\n>> some of the variables rather than including them in the url. The write\n>> modules need not be working in a gitweb installation like repo.or.cz,\n>> so we will also have an option to disable the write modules.\n>\n> Frankly, I'm not very excited from this. First, I recommend that you\n> completely separate splitting of gitweb to smaller pieces (without any\n> major conceptual changes) both in the proposal and in actual\n> submissions.\n>\n> Second, you should justify the introduction of session management and\n> templating. What is the point and why is it neccessary for your project\n> goals?\n>\n\nSession management reduces the length of URL and templating reduces\nthe amount of HTML in the actual code.\n\n>> b) Write modules of the client:\n>>\n>>   1. Add Existing repositories to the gitweb -- This will list the\n>> given repo into gitweb config\n>>   2. Create new/Clone repositories into a given path [git init | git\n>> clone] -- This will create new repo and list it\n>>   3. Add/Remove/Move files [git add | git rm | git mv]\n>>   4. Stage/Unstage files [git add | git reset]\n>>   5. Add files to ignore list when u click on 'Ignore' link\n>>   6. Discard changes to a file in working copy [git reset]\n>>   7. Commit to the repository with a log message and an optional\n>> sign-off [git commit]\n>>   8. Switch branches [git branch]\n>>   9. A simple branch merging* [git merge]\n>>  10. Creating tags [git tag]\n>>  11. Checkout code to a specific commit or branch or tag [git checkout]\n>>  12. Push to a remote branch [git push]\n>>  13. Fetch/Pull from a remote branch [git fetch | git pull]\n>>  14. Garbage collection [git gc]\n>\n> Sounds reasonable. What am I missing is a way to edit files through the\n> web interface. Also, please spec in more detail the difference between\n> [8] and [11].\n\n[8] includes creating and deleting branches along with listing and\nswitching where as [11] includes just switching and also allows to\nswitch between commits and tags.\n\n>\n>>  15. Search for a part of code [git grep]\n>\n> This is already supported by gitweb. And it's not a \"write\" operation.\n> ;-)\n\nI wrote it here because I would like to integrate it with content\nhistory browser functionality later.\n\n>> c) Read modules of the client: (most of this need not be written, just\n>> need to be organised)\n>>\n>>   1. See the status of repository [git status]\n>\n> How will you integrate this with the existing 'tree' action?\n\nNo, there will be a seperate page for it which executes git status command.\n\n>>   3. List all the commits with pagination [git log]\n>\n> Why?\n\nIt's nothing but the current gitweb does.\n\n>\n>>   4. With every commit we can\n>>          * Visualise trees [git ls-tree]\n>>          * Visualise files and diffs [git show]\n>>          * Visualise annotations [git blame]\n>>   5. List all branches including remote ones [git branch]\n>>   6. Search commits, branches, authors etc..\n>\n> I.e. what we already do?\n\nYes\n\n>\n>> d) Usage of the client:\n>> * Install on intranet - A company when installs this gitweb along with\n>> some other login and account managing scripts will be able to order\n>> their employees to login and ask them to work on the code with out the\n>> security risk of providing ssh access to the git repository host.\n>\n> Frankly, the net security risk of providing git-shell access is probably\n> lower than using a web interface. ;-) However, I still see this making\n> many corporate people happy and opening doors to less canonical Git\n> usecases - it also enables \"zero config\" ability to contribute to Git\n> projects, desirable for less technical users (artists etc.).\n\nYes.\n\n>> I will try to make sure that the patches to be as small as possible\n>> and easily reviewable. Also my vacation starts on May 2nd and ends on\n>> August 1st. So most of the project work will be done during the start\n>> of the GSoC project rather than in the end.\n>\n> Great!\n>\n>> [May 4th week - June 1st week]\n>> Split the whole code of gitweb into framework structure and setup\n>> library files along with installation and configuration.\n>\n> I think this might end up being rather tricky, and would appreciate you\n> detailing this out a bit more, including some expected dates for initial\n> patch submissions.\n\nWe haven't yet decided on how to split gitweb, so I would like to give\na bit more details about this after I take the majority opinion on how\nto split gitweb.\n\n>\n>> [July 2nd week]\n>> Check for any possible and potential security loopholes or bugs\n>\n> I appreciate that you are thinking about this, though I'm less sure if\n> this can be efficiently done as a batch job like this.\n>\n\nI don't think so. Anyway, let's try it. :-)\n\n> --\n>                                Petr \"Pasky\" Baudis\n> http://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n>\n\nPlease ask me if you have any other doubts regarding this proposal.\n\nThanks\n-pavan\n"},{"id":"139868","messageId":"vpqeiicey0d.fsf@bauges.imag.fr","threadId":"23468","inReplyTo":"u2ve72faaa81004182346zdf4bd0b3m3341717b1555c0a9@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-19T06:50:58Z","receivedAt":"2010-04-19T06:50:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Pavan Kumar Sunkara writes:\n\n> Session management reduces the length of URL\n\n... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,\nwhich is in my opinion a must-have for gitweb.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"139870","messageId":"7vfx2rsy6y.fsf@alter.siamese.dyndns.org","threadId":"23468","inReplyTo":"vpqeiicey0d.fsf@bauges.imag.fr","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-19T07:23:17Z","receivedAt":"2010-04-19T07:23:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Pavan Kumar Sunkara writes:\n>\n>> Session management reduces the length of URL\n>\n> ... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,\n> which is in my opinion a must-have for gitweb.\n\nThese self-contained URL are used in bookmarks and e-mails to the mailing\nlist. I think \"the length of URL\" is a red herring at best, and shortened\nURL that is not self-contained is not an advantage at all.\n\nOn the other hand, a proposal about giving multiple clients access to\ntheir own individual server-side checkouts (ala \"workspace\" in DELTA-V)\nwould require some mechanism to maintain the state on the server end, and\nsession management would be one ingredient necessary to achieve that.\n\nWhen I heard that somebody wants to do a \"write support\" in gitweb, I\nnaturally thought the proposal was about implementing RFC3253 using git as\na backend. I think it would be a reasonable thing to do (as opposed to\ncoming up with an ad-hoc \"write support\" mechanism that is not compatible\nwith anybody else), but on the other hand it might be a bit too ambitious\nfor a one-student summer project.\n"},{"id":"139873","messageId":"v2me72faaa81004190038y4aeefa80g9f60bb3b1e795e4b@mail.gmail.com","threadId":"23468","inReplyTo":"7vfx2rsy6y.fsf@alter.siamese.dyndns.org","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T07:38:26Z","receivedAt":"2010-04-19T07:38:26Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n>\n>> Pavan Kumar Sunkara writes:\n>>\n>>> Session management reduces the length of URL\n>>\n>> ... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,\n>> which is in my opinion a must-have for gitweb.\n>\n> These self-contained URL are used in bookmarks and e-mails to the mailing\n> list.  I think \"the length of URL\" is a red herring at best, and shortened\n> URL that is not self-contained is not an advantage at all.\n\nYeah, I agree to that.\n\n> On the other hand, a proposal about giving multiple clients access to\n> their own individual server-side checkouts (ala \"workspace\" in DELTA-V)\n> would require some mechanism to maintain the state on the server end, and\n> session management would be one ingredient necessary to achieve that.\n\nSo, why don't we do like this,\nThere will be no need of session management when gitweb is installed\nin some site like repo.or.cz which needs copy'n'paste URLs\nbut there will be session management when the write modules are\nenabled and when gitweb is installed locally or on intranet (basically\nwhen it is used to work on a repo).\n\nWhat do you say ?\n\n> When I heard that somebody wants to do a \"write support\" in gitweb, I\n> naturally thought the proposal was about implementing RFC3253 using git as\n> a backend.  I think it would be a reasonable thing to do (as opposed to\n> coming up with an ad-hoc \"write support\" mechanism that is not compatible\n> with anybody else), but on the other hand it might be a bit too ambitious\n> for a one-student summer project.\n>\n\nSorry but I don't know what it is.\nThe current average git used are in need of a git client and git-gui\nis not doing a good job of it. So, this proposal solves it by\nproviding client features inside gitweb itself. :-)\n\n-pavan\n"},{"id":"139885","messageId":"20100419090734.GA10939@machine.or.cz","threadId":"23468","inReplyTo":"v2me72faaa81004190038y4aeefa80g9f60bb3b1e795e4b@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-19T09:07:34Z","receivedAt":"2010-04-19T09:07:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Apr 19, 2010 at 01:08:26PM +0530, Pavan Kumar Sunkara wrote:\n> On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano wrote:\n> > On the other hand, a proposal about giving multiple clients access to\n> > their own individual server-side checkouts (ala \"workspace\" in DELTA-V)\n> > would require some mechanism to maintain the state on the server end, and\n> > session management would be one ingredient necessary to achieve that.\n\nBut what if I will want to give a link to my \"workspace\" to someone\nelse? You can embed workspace id in the URL, in fact you would probably\njust use it instead of project name completely naturally. I still don't\nsee any need for sessions.\n\n> So, why don't we do like this,\n> There will be no need of session management when gitweb is installed\n> in some site like repo.or.cz which needs copy'n'paste URLs\n> but there will be session management when the write modules are\n> enabled and when gitweb is installed locally or on intranet (basically\n> when it is used to work on a repo).\n> \n> What do you say ?\n\nI think it will be best to discuss session support (and work on\nimplementing it) when actual features where it is essential will\ncome up. So far, I'm unable to foresee them, but if we discuss it\nlater in conjunction with some concrete features, perhaps it will\nbe clearer.\n\n> > When I heard that somebody wants to do a \"write support\" in gitweb, I\n> > naturally thought the proposal was about implementing RFC3253 using git as\n> > a backend.  I think it would be a reasonable thing to do (as opposed to\n> > coming up with an ad-hoc \"write support\" mechanism that is not compatible\n> > with anybody else), but on the other hand it might be a bit too ambitious\n> > for a one-student summer project.\n\nI think that would be something entirely different, and IMO even\nmuch less interesting. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139889","messageId":"201004191243.24209.jnareb@gmail.com","threadId":"23468","inReplyTo":"20100418195623.GA3563@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-19T10:43:22Z","receivedAt":"2010-04-19T10:43:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:\n> On Sun, Apr 18, 2010 at 07:50:17PM +0200, Jakub Narebski wrote:\n\n>> So it is intended, I guess, more like git-instaweb or webmin, not like\n>> administrative parts of Girocco (or repo.or.cz), GitHub, Gitorious or\n>> InDefero. Probably authentication and authorization would not be needed\n>> then, if it is to be run as web interface but locally...\n> \n> If the project is a success, I wanted to use it for mob branch editing\n> on repo.or.cz. It could also be used as open-source Gist alternative.\n\nFor that you would need editing file / editing contents action, but\nthis is explicitely excluded in current version of Pavan's proposal :-(\n\n> But it needs to be coded so that it does not require an actual checked\n> out copy (which shouldn't be too much hassle).\n\nIt would require using 'git hash-object -t blob -w --stdin' (from body\nsubmitted via POST from textarea) plus 'git update-index --cacheinfo'.\nThere is however complication that you would need to do open2/open3\nbecause git-hash-object would require bidirectional communication unless\nyou would use temporary file (command_bidi_pipe in Git.pm, untested).\n\n>> Currently to install gitweb you have to copy *one* script, and a few\n>> static files (2 x image, CSS, JavaScript). You can configure it using\n>> \"make gitweb\" with appropriate options, you can simply edit gitweb script,\n>> or you can leave this to the gitweb config file.\n> \n> I don't really think things can get *any* more complicated than \"also\n> copy over this directory recursively\", do they?\n\nLet's check what gitweb/INSTALL says currently\n\n $ make prefix=/usr gitweb ;# as yourself\n # cp gitweb/git* /var/www/cgi-bin/ ;# as root\n\nWTF with 'gitweb/git*' glob? \n\nAh, later there is \"Build example\", which is\n\n - To install gitweb to /var/www/cgi-bin/gitweb/ when git wrapper\n is installed at /usr/local/bin/git and the repositories (projects)\n we want to display are under /home/local/scm, you can do\n\n make GITWEB_PROJECTROOT=\"/home/local/scm\" \\\n GITWEB_JS=\"/gitweb/gitweb.js\" \\\n GITWEB_CSS=\"/gitweb/gitweb.css\" \\\n GITWEB_LOGO=\"/gitweb/git-logo.png\" \\\n GITWEB_FAVICON=\"/gitweb/git-favicon.png\" \\\n bindir=/usr/local/bin \\\n gitweb\n\n cp -fv ~/git/gitweb/gitweb.{cgi,js,css} \\\n ~/git/gitweb/git-{favicon,logo}.png \\\n /var/www/cgi-bin/gitweb/\n\nWTF with '~/git/gitweb'... ehh, that one is mine, I guess...\n\n\nSo additional step would be\n\n cp -fvR gitweb/lib /var/www/cgi-bin/ ;# as root\n\n\nI hope that we could make installing gitweb as easy as\n\n make webscriptdir=/var/www/cgi-bin/ \\\n gitweb-install\n \nor in more complicated case (gitweb modules not installed in cgi-bin)\n\n make webscriptdir=/var/www/cgi-bin/gitweb \\\n GITWEB_BASE=\"/gitweb/\" \\\n GITWEBPERLLIB=/usr/local/lib/perl5 \\\n gitweb-install\n\nor something like that (I do not know any standard for the name of build\nconfiguration variable which tells where to install web aplication; \ndo you?)\n\n>> Also there is a question _how_ to split gitweb into modules, \n>> e.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should\n>> be split. But I guess any splitting would suffice; we need to provide\n>> a way to build and install split gitweb. \n>> \n>> Split can be as simple as:\n>> \n>> Makefile, or Makefile.PL, or Build.PL\n>> gitweb.perl\n>> static/git-logo.png\n>> static/git-favicon.png\n>> static/gitweb.css\n>> static/gitweb.js\n>> lib/Gitweb/Utils.pm (Gitweb::Utils)\n>> lib/Gitweb/Editor.pm (Gitweb::Editor, for GSoC2010, if it gets accepted)\n> \n> Exactly! I think we can do this reasonably incrementally; if something\n> is not working out, we can move it again later. Let's not overengineer\n> stuff. I think it would make sense to just split out something like\n> Gitweb::Git (for Git invocations), Gitweb::CGI (for CGI parsing and\n> HTML output toolkit) and perhaps Gitweb::Util for misc. stuff. Then,\n> if we feel like it, maybe we can start splitting out things more, like\n> Gitweb::CGI::Blame, but I don't think that's even neccessary for now.\n\nWell, I would perhaps start simply with \n\n gitweb.perl\n lib/Gitweb.pm\n\nWe can modify file organization later; what's important is the build\ninfrastructure (even if it is instruction in gitweb/INSTALL).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139890","messageId":"20100419115113.GC3563@machine.or.cz","threadId":"23468","inReplyTo":"201004191243.24209.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-19T11:51:13Z","receivedAt":"2010-04-19T11:51:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:\n> On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:\n> > If the project is a success, I wanted to use it for mob branch editing\n> > on repo.or.cz. It could also be used as open-source Gist alternative.\n> \n> For that you would need editing file / editing contents action, but\n> this is explicitely excluded in current version of Pavan's proposal :-(\n\nIs it? I see it only being omitted.\n\n> > But it needs to be coded so that it does not require an actual checked\n> > out copy (which shouldn't be too much hassle).\n> \n> It would require using 'git hash-object -t blob -w --stdin' (from body\n> submitted via POST from textarea) plus 'git update-index --cacheinfo'.\n\nYes. Not a whole lot of effort, seems to me. A downside is that you\ncannot use the working tree - index dichotomy, but life isn't perfect.\n\n> There is however complication that you would need to do open2/open3\n> because git-hash-object would require bidirectional communication unless\n> you would use temporary file (command_bidi_pipe in Git.pm, untested).\n\nI think even just going through a temporary file is fine for initial\nimplementation.\n\n> So additional step would be\n> \n> cp -fvR gitweb/lib /var/www/cgi-bin/ ;# as root\n\nYes!\n\n> I hope that we could make installing gitweb as easy as\n> \n> make webscriptdir=/var/www/cgi-bin/ \\\n> gitweb-install\n> \n> or in more complicated case (gitweb modules not installed in cgi-bin)\n> \n> make webscriptdir=/var/www/cgi-bin/gitweb \\\n> GITWEB_BASE=\"/gitweb/\" \\\n> GITWEBPERLLIB=/usr/local/lib/perl5 \\\n> gitweb-install\n> \n> or something like that (I do not know any standard for the name of build\n> configuration variable which tells where to install web aplication; \n> do you?)\n\nIdeally, yes, but that's not directly tied to the splitting effort.\n(No clue about the configuration variable.)\n\n> Well, I would perhaps start simply with \n> \n> gitweb.perl\n> lib/Gitweb.pm\n> \n> We can modify file organization later; what's important is the build\n> infrastructure (even if it is instruction in gitweb/INSTALL).\n\nThat sounds like the best way. :)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139891","messageId":"20100419115727.GB10939@machine.or.cz","threadId":"23468","inReplyTo":"u2ve72faaa81004182346zdf4bd0b3m3341717b1555c0a9@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-19T11:57:27Z","receivedAt":"2010-04-19T11:57:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Apr 19, 2010 at 12:16:31PM +0530, Pavan Kumar Sunkara wrote:\n> On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis wrote:\n> > Frankly, I'm not very excited from this. First, I recommend that you\n> > completely separate splitting of gitweb to smaller pieces (without any\n> > major conceptual changes) both in the proposal and in actual\n> > submissions.\n> >\n> > Second, you should justify the introduction of session management and\n> > templating. What is the point and why is it neccessary for your project\n> > goals?\n> >\n> \n> Session management reduces the length of URL and templating reduces\n> the amount of HTML in the actual code.\n\n...which is bad?\n\nI don't see the value in session management; making the URL contain less\ninformation is not _good_, it is _very_ _bad_, since you can't use the\nUniform Resource Locator to locate resources anymore.\n\nIntroduction of templating would mean huge changes (not only addition of\nthe templater) for seemingly no warranted reason. I mean, if we were to\nstart writing gitweb from scratch, perhaps a templater engine *might*\nwarrant some consideration, but I don't see any itch we want to scratch\nby introducing templating now. And no connectoin with the project at\nhand.\n\n> >> b) Write modules of the client:\n> >>  15. Search for a part of code [git grep]\n> >\n> > This is already supported by gitweb. And it's not a \"write\" operation.\n> > ;-)\n> \n> I wrote it here because I would like to integrate it with content\n> history browser functionality later.\n\nI don't understand, can you elaborate?\n\n> >> c) Read modules of the client: (most of this need not be written, just\n> >> need to be organised)\n> >>\n> >>   1. See the status of repository [git status]\n> >\n> > How will you integrate this with the existing 'tree' action?\n> \n> No, there will be a seperate page for it which executes git status command.\n\nAnd just passes through its plaintext output? Well, I suppose that could\ndo for starters.\n\n> > --\n> >                                Petr \"Pasky\" Baudis\n> > http://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n> >\n> \n> Please ask me if you have any other doubts regarding this proposal.\n\nCould you clarify your attitude to the support for mode without checked\nout working copy, using just the index, that we are discussing with\nJakub and I already mentioned to you in the past?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139892","messageId":"vpq8w8j1vb7.fsf@bauges.imag.fr","threadId":"23468","inReplyTo":"20100419090734.GA10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-19T12:27:40Z","receivedAt":"2010-04-19T12:27:40Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Petr Baudis writes:\n\n> On Mon, Apr 19, 2010 at 01:08:26PM +0530, Pavan Kumar Sunkara wrote:\n>> On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano wrote:\n>> > On the other hand, a proposal about giving multiple clients access to\n>> > their own individual server-side checkouts (ala \"workspace\" in DELTA-V)\n>> > would require some mechanism to maintain the state on the server end, and\n>> > session management would be one ingredient necessary to achieve that.\n>\n> But what if I will want to give a link to my \"workspace\" to someone\n> else? You can embed workspace id in the URL, in fact you would probably\n> just use it instead of project name completely naturally. I still don't\n> see any need for sessions.\n\nOne use-case I'd like this work to be able to address is:\n\nMany of my colleagues don't want to use Git. If I send them a mail\nwith the cut-and-paste-ready \"git clone\" command, they'll still reply\nasking for an attachment to an email, and they'll send me their\nmodifications the same way.\n\nIn a good write-enabled web interface, they'd browse the repository\nonline, pick a file, and the download page would point them to a URL\ncontaining the filename, and the base commit, with a form to upload a\nnew version of the file.\n\nSome time later, they could re-use the same URL, and upload the\nmodified version of the file. Actually, I could even do the first step\nmyself, and send them an email with the attachment and the URL, and\nthey'd upload their version whenever they want. The upload should\ncreate a commit in a separate branch, starting from the base commit\ncontained in the URL. I could do the merge myself later in case of\nnon-fast forward.\n\nThat's a real senario, and I believe it would be a rather common\nuse-case of a web-based git client: a power-user prepares the work,\nand sends well-prepared URL to newbies. This really requires GET\nparameters.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"139895","messageId":"p2we72faaa81004190557t240823bcu63f95b0f8a885cbb@mail.gmail.com","threadId":"23468","inReplyTo":"vpq8w8j1vb7.fsf@bauges.imag.fr","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T12:57:33Z","receivedAt":"2010-04-19T12:57:33Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"All of us are supporting using GET parameters rather than sessions for\nproject name and others which is fine for me as the reasons are valid.\nBut I would like to develop sessions manager incase they want to use\nauthentication support.\n\nWhat do you say ?\n\n-pavan\n"},{"id":"139896","messageId":"vpqsk6rmvna.fsf@bauges.imag.fr","threadId":"23468","inReplyTo":"p2we72faaa81004190557t240823bcu63f95b0f8a885cbb@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-19T13:14:49Z","receivedAt":"2010-04-19T13:14:49Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Pavan Kumar Sunkara writes:\n\n> All of us are supporting using GET parameters rather than sessions for\n> project name and others which is fine for me as the reasons are valid.\n> But I would like to develop sessions manager incase they want to use\n> authentication support.\n>\n> What do you say ?\n\nThat doesn't seem contradictory. You can have login/password as\ncookies or session variables, and other parameters within the URL.\n\nThen, if I send you a URL pointing to a write-enabled page which\nrequires authentication, and you click it, you'll be prompted for your\nlogin/password before you can proceed, but after that, you'll still be\nredirected to the right page.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"139917","messageId":"201004191900.12529.jnareb@gmail.com","threadId":"23468","inReplyTo":"w2pe72faaa81004182334xd6fc56d7o31420ca4af867cc2@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-19T17:00:10Z","receivedAt":"2010-04-19T17:00:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:\n> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski wrote:\n>> On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:\n\n>>> =====================================================\n>>>\n>>> Splitting gitweb and developing write functionalites\n>>> Student: Pavan Kumar Sunkara\n>>>\n>>> This project aims at splitting and organising the 6800 lines code of\n>>> gitweb.pl into a nicely structured set of files. Not only providing\n>>> the browsing functionalities in gitweb, but it also aims at developing\n>>> functionalities for working on a git repository.\n>>\n>> First, a question: do you feel proficient enough in Perl (and in web\n>> scripting in Perl), or do you prefer other programming language for\n>> web, like e.g. Python? If you feel like you would do better programming\n>> in Python (or PHP, or Ruby) rather than in Perl, you could write the\n>> main part of this GSoC project in said language, and provide only hooks\n>> into gitweb (with the help of developers on git mailing list).\n>\n> I don't know perl but learning it and becoming proficient in it won't be a\n> matter for me. I believe I am a fast learner and I am a computer science\n> student in the top university of India. I learnt python in an hour and\n> became proficient in it by a week. So learning perl won't be a matter for\n> me.\n\nI can agree that you would be able to learn Perl in a week. I do not\nthink however that you can become proficient in Perl (and neither in any\nother non-trivial programming language) in such short time. The question\nremains if you can be proficient enough for the task in question...\n\n>> Second, it would probably be not \"splitting ... into ... a set of\n>> files\", but rather \"splitting gitweb into modules\" (see e.g.\n>> Web::Simple, SVN::Web, etc).\n>>\n> I would like to take the majority opinion on how to split gitweb.\n\nErrr... my comment was about technical language / jargon used...\n\nAs to \"I would like to take the majority opinion on how to split gitweb\":\nin my opinion you would need to have your own idea on how to split gitweb\nyourself, to avoid possibility of wasting time on bikeshedding[1]. \nOf course this would be based on discussion here on git mailing list.\nAll of this assuming that this project would get accepted.\n\n[1] http://en.wikipedia.org/wiki/Bikeshed\n\n>> \"It aims at developing functionalities for working on a git repository.\"\n>> Not only this is not grammatical, but also doesn't tell us the goal\n>> of your project. Is it something to edit files and create commits via\n>> web, be to git-gui what git-instaweb is to gitk? Is it about editing\n>> gitweb-specific configuration, like README/README.html and 'description'\n>> file from web browser? Is it managing git repositories, i.e. create,\n>> fork or clone and mirror repositories, something that Gerrit does for\n>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?\n>>\n> I think you understood it from the later part of my proposal.\n\nYes, I found it in later parts of proposal, but don't you think that\nthis goal of this project should be stated upfront, so that one can\nknow what this project is to be about from project description itself?\n\n>>> * User friendly graphical interface with smart UI design when\n>>> compared to any other git clients or browsers.\n>>\n>> This is rather vague for a goal. Do you want to be able to edit\n>> files and commit them? To add new files and remove tracked files\n>> (or just untrack them)? To cherry-pick, revert, amend commit?\n>> To switch between branches and reqwind a branch? To run and visualize\n>> git-bisect? To merge branches and resolve merge conflicts? To rebase\n>> and resolve rebase conflicts?\n> \n> Yes, exactly. I think you haven't read the whole proposal before writing\n> this. :-)\n\nI have not. I got it from discussion in parallel subthread, so I asked\nfor clarification. But I should have to read the whole proposal, or\nknow extra information to get what you were trying to say here. \nBe specific (but not too detailed), not vague in describing goals.\n\n>>> * gitweb.tpl -- The template of the web page (GUI) in which\n>>> modules are embedded\n>>\n>> Errrr... what? Gitweb currently does not use templating engine.\n>> There are no templating engines in Perl core, writing yet another one\n>> only for gitweb would be stupid, and choosing one would I guess result\n>> in bikeshedding spanning whole summer and then some (which one to\n>> choose: Template Toolkit with its domain specific language, Haml-like\n>> perlish templates of Template::Declare and Markapl, or pure (X)HTML\n>> templates of Template::Semantic and HTML::Zoom?).\n>>\n>> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC\n>> model, containing subroutines responsible for the look of gitweb?\n>>\n> I would like to add a small 50 lines code for templater class which does\n> string substitution and embed the module output into tpl file. This method\n> reduces the subroutines like git_header_html etc.. A small example of\n> templater class can be found at http://matetelki.com/blog/?p=71. It isn't\n> exactly the same i use but you get the basic idea. right ?\n\nCurrently gitweb does not use any templating engine. Adding it would\nbe additional work, in my opinion not really necesary for the goals of\nproject (splitting gitweb is more on less needed to be able to add\nlarge new feature, such as committool / \"write\" bit). I don't think\nthere is enough time to (optionally) code and add templating to gitweb.\n\nAdditionally, while adding very simple templating class wouldn't be\nto much violation of programming guidelines (and for example both\nMojolicius and Dancer web micro-frameworks include their own simple\ntemplating system), I am afraid that simple string / variable \nsubstitution would be not enough for gitweb: loops and conditionals\nwould also be required. Also we would probably want for templating\nsystem to automatically escape (when requested). So templating engine\ngrows... and then it would really be better to just use one of existing\ntemplating modules from CPAN (http://search.cpan.org), or add adapter\nto one of templating system from CPAN (like Catalyst web framework\ndoes it).\n\nAlso if you are not proficient in Perl, I would be aftraid that your\nhomebrew templating engine would affect gitweb performance...\n\n\nIn short: no time to add templating support to gitweb.\n\n>>> * modules (dir) -- directory containing the write and read modules.\n>>> * lib (dir) -- some basic files like config, error_handler,\n>>> templater, redirecter, htmlHelper etc..\n>>\n>> I'm not sure about modules/ directory: wouldn't lib/ be enough?\n>> What needs to be in modules/ that cannot be put in lib/?\n\nI guess (please correct me if I am wrong) that lib/ would contain modules\n*required* by gitweb, and modules/ would contain *optional* modules\nneeded for extra functionality (for extra features).\n\n>>> The new script includes config and other basic files, checks\n>>> the URL, parses it, detects the module, manage session and includes\n>>> the proper module.\n>>\n>> O.K., so after splitting the main gitweb.perl file (from which\n>> gitweb.cgi would be created during build) includes configuration\n>> (hmmm... shouldn't default configuration and perhaps reading\n>> site-specific configuration too be put into separate Perl module?),\n>> dispatch (checking and parsing URL, verifying parameters, and\n>> choosing action to run), and checking which extra modules (and\n>> therefore which actions) are available.\n>>\n>> \"Manage session\"... err, current gitweb does not need session\n>> management. Would the \"write\" module require it, even if we can assume\n>> that you are the only client like with git-instaweb, and authentication\n>> is not required? I would also recommend to not reinwent the wheel,\n>> and if you feel that \"write\" module really needs session management,\n>> use some existing CPAN module for it like e.g. CGI::Session, or at least\n>> borrow (some) code from it.\n>>\n> I mean wouldn't using session be good thing to add. It doesn't need to use\n> parameters like project name all the time in the URL.\n\nUsing sessions is not without cost: you would (usually) need to store\nextra information on the server.\n\nAlso one usually wants for URLs to be bookmarkeable. One would want\nto be able to send link to be copy'n'pasted.\n\nIf sessions are to make gitweb URLs shorter: forget it. First, it would\nbe not necessary for your project. Second, this is not the way to have\nshorter URLs.\n\nSee also the whole idea of stateless REST interface.\n\n>>> b) Write modules of the client:\n>>>\n>>> 1. Add existing repositories to the gitweb -- This will list the\n>>> given repo into gitweb config\n>>\n>> Note that if gitweb scans for repositories ($projects_list is\n>> a directory, not a file with the list of projects), gitweb would detect\n>> new repository automatically. This feature (autodetecting\n>> repositories) is fore example requirement on git.kernel.org.\n>>\n> Let us say if there are multiple repositories in multiple paths, wouldn't it\n> be good to add a single project. This option will be available along with\n> scanning $projects_root.\n\nIf gitweb is configured to scan for repositories, adding existing git\nrepository to gitweb doesn't make sense. If gitweb is configured to\nuse static file with list of repositories, of course it would make\nsense... but then the question is how would one specify location of\na new repository to add.\n \n\n>>> 12. Push to a remote branch [git push]\n>>> 13. Fetch/Pull from a remote branch [git fetch | git pull]\n>>\n>> You would need support for either editing config, or for interface to\n>> [git remote add] first, otherwise the only remote available would be\n>> 'origin'. Unless you are interested in pushing to / fetching from\n>> repository given by URL...\n>>\n> I think i missed that point. all functionalites with \"git remote\" will be\n> added too.\n\nGood.\n\n>>> d) Usage of the client:\n>>>\n>>> This client can be used in 2 ways.\n>>>\n>>> * Install a local version using instaweb - The gitweb will be only\n>>> accessible by you. You can browse through the git repository using\n>>> read modules and simultaneously work on them using write modules.\n>>\n>> This part could be doable during GSoC 2010 (if this project gets\n>> accepted), I think.\n> \n> Yes. This is the main thing that is needed for a average git user.\n\nThe main simplification is that we do not need authentication here,\nonly perhaps requirement that server is 'localhost'.\n\n>>> * Install on intranet - A company when installs this gitweb along with\n>>> some other login and account managing scripts will be able to order\n>>> their employees to login and ask them to work on the code with out the\n>>> security risk of providing ssh access to the git repository host.\n>>> * Install on web - Just like normal gitweb, or enable write modules to\n>>> look like gist.github.com\n>>\n>> This would require authentication support, which I think might be too\n>> much for GSoC.\n> \n> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I\n> hope to provide an authentication wrapper for gitweb in future.\n \nWell, unless there would be time for it after you finish all other work,\nbut it is a bit unlikely.\n\n>>> * Developing API to work with gitweb for storing information in\n>>> form of a git repository\n>>\n>> What you mean by that?\n>>\n> I mean, I will be providing an web API wrapper for gitweb which can be used\n> by other web developers to store any information they get into a git\n> repository form and can use it to see the changes they made to the\n> information step by step.\n\nIt doesn't tell me much either. Do you mean some kind of REST API here,\nto be used from other clients, or something like that? \n\nAnyway I'd rather you put it in \"if I have time\" pile...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139919","messageId":"u2ze72faaa81004191055t13ad6f2hbdcc319260cbabcf@mail.gmail.com","threadId":"23468","inReplyTo":"201004191900.12529.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T17:55:56Z","receivedAt":"2010-04-19T17:55:56Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"2010/4/19 Jakub Narebski :\n> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:\n>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski wrote:\n>>> On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:\n>\n>>>> =====================================================\n>>>>\n>>>> Splitting gitweb and developing write functionalites\n>>>> Student:        Pavan Kumar Sunkara\n>>>>\n>>>> This project aims at splitting and organising the 6800 lines code of\n>>>> gitweb.pl into a nicely structured set of files. Not only providing\n>>>> the browsing functionalities in gitweb, but it also aims at developing\n>>>> functionalities for working on a git repository.\n>>>\n>>> First, a question: do you feel proficient enough in Perl (and in web\n>>> scripting in Perl), or do you prefer other programming language for\n>>> web, like e.g. Python?  If you feel like you would do better programming\n>>> in Python (or PHP, or Ruby) rather than in Perl, you could write the\n>>> main part of this GSoC project in said language, and provide only hooks\n>>> into gitweb (with the help of developers on git mailing list).\n>>\n>> I don't know perl but learning it and becoming proficient in it won't be a\n>> matter for me. I believe I am a fast learner and I am a computer science\n>> student in the top university of India. I learnt python in an hour and\n>> became proficient in it by a week. So learning perl won't be a matter for\n>> me.\n>\n> I can agree that you would be able to learn Perl in a week.  I do not\n> think however that you can become proficient in Perl (and neither in any\n> other non-trivial programming language) in such short time.  The question\n> remains if you can be proficient enough for the task in question...\n\nI can learn perl in 3 hours. Becoming proficient in perl is just\nknowing about all the majorly used inbuilt functions and libraries.\nComing to the concepts of programming, I already know a lot about it\nalong with Data structures and algortihms. So you need not doubt me on\nthis.\n\n>>> Second, it would probably be not \"splitting ... into ... a set of\n>>> files\", but rather \"splitting gitweb into modules\" (see e.g.\n>>> Web::Simple, SVN::Web, etc).\n>>>\n>> I would like to take the majority opinion on how to split gitweb.\n>\n> Errr... my comment was about technical language / jargon used...\n>\n> As to \"I would like to take the majority opinion on how to split gitweb\":\n> in my opinion you would need to have your own idea on how to split gitweb\n> yourself, to avoid possibility of wasting time on bikeshedding[1].\n> Of course this would be based on discussion here on git mailing list.\n> All of this assuming that this project would get accepted.\n>\n> [1] http://en.wikipedia.org/wiki/Bikeshed\n\nSorry about that.\n\nI have already given my idea in the proposal. I would like to hear\nyour opinions and implement the majority opinion if my idea is full\nof flaws. That is what I meant by the line.\n\n>>> \"It aims at developing functionalities for working on a git repository.\"\n>>> Not only this is not grammatical, but also doesn't tell us the goal\n>>> of your project.  Is it something to edit files and create commits via\n>>> web, be to git-gui what git-instaweb is to gitk?  Is it about editing\n>>> gitweb-specific configuration, like README/README.html and 'description'\n>>> file from web browser?  Is it managing git repositories, i.e. create,\n>>> fork or clone and mirror repositories, something that Gerrit does for\n>>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?\n>>>\n>> I think you understood it from the later part of my proposal.\n>\n> Yes, I found it in later parts of proposal, but don't you think that\n> this goal of this project should be stated upfront, so that one can\n> know what this project is to be about from project description itself?\n\nI thought it should be described later in the \"Describe your project\nin more detail\" section. So, I didn't go into details here.\n\n>>>>    * User friendly graphical interface with smart UI design when\n>>>> compared to any other git clients or browsers.\n>>>\n>>> This is rather vague for a goal.  Do you want to be able to edit\n>>> files and commit them?  To add new files and remove tracked files\n>>> (or just untrack them)?  To cherry-pick, revert, amend commit?\n>>> To switch between branches and reqwind a branch?  To run and visualize\n>>> git-bisect?  To merge branches and resolve merge conflicts?  To rebase\n>>> and resolve rebase conflicts?\n>>\n>> Yes, exactly. I think you haven't read the whole proposal before writing\n>> this. :-)\n>\n> I have not.  I got it from discussion in parallel subthread, so I asked\n> for clarification.  But I should have to read the whole proposal, or\n> know extra information to get what you were trying to say here.\n> Be specific (but not too detailed), not vague in describing goals.\n\nOK.\n\n>>>>    * gitweb.tpl -- The template of the web page (GUI) in which\n>>>>      modules are embedded\n>>>\n>>> Errrr... what?  Gitweb currently does not use templating engine.\n>>> There are no templating engines in Perl core, writing yet another one\n>>> only for gitweb would be stupid, and choosing one would I guess result\n>>> in bikeshedding spanning whole summer and then some (which one to\n>>> choose: Template Toolkit with its domain specific language,  Haml-like\n>>> perlish templates of Template::Declare and Markapl, or pure (X)HTML\n>>> templates of Template::Semantic and HTML::Zoom?).\n>>>\n>>> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC\n>>> model, containing subroutines responsible for the look of gitweb?\n>>>\n>> I would like to add a small 50 lines code for templater class which does\n>> string substitution and embed the module output into tpl file. This method\n>> reduces the subroutines like git_header_html etc.. A small example of\n>> templater class can be found at http://matetelki.com/blog/?p=71. It isn't\n>> exactly the same i use but you get the basic idea. right ?\n>\n> Currently gitweb does not use any templating engine.  Adding it would\n> be additional work, in my opinion not really necesary for the goals of\n> project (splitting gitweb is more on less needed to be able to add\n> large new feature, such as committool / \"write\" bit).  I don't think\n> there is enough time to (optionally) code and add templating to gitweb.\n>\n> Additionally, while adding very simple templating class wouldn't be\n> to much violation of programming guidelines (and for example both\n> Mojolicius and Dancer web micro-frameworks include their own simple\n> templating system), I am afraid that simple string / variable\n> substitution would be not enough for gitweb: loops and conditionals\n> would also be required.  Also we would probably want for templating\n> system to automatically escape (when requested).  So templating engine\n> grows... and then it would really be better to just use one of existing\n> templating modules from CPAN (http://search.cpan.org), or add adapter\n> to one of templating system from CPAN (like Catalyst web framework\n> does it).\n>\n> Also if you are not proficient in Perl, I would be aftraid that your\n> homebrew templating engine would affect gitweb performance...\n>\n>\n> In short: no time to add templating support to gitweb.\n\nOk. If everyone feels the same I would like remove it from the proposal.\n\n>\n>>>>    * modules (dir) -- directory containing the write and read modules.\n>>>>    * lib (dir) -- some basic files like config, error_handler,\n>>>> templater, redirecter, htmlHelper etc..\n>>>\n>>> I'm not sure about modules/ directory: wouldn't lib/ be enough?\n>>> What needs to be in modules/ that cannot be put in lib/?\n>\n> I guess (please correct me if I am wrong) that lib/ would contain modules\n> *required* by gitweb, and modules/ would contain *optional* modules\n> needed for extra functionality (for extra features).\n\nYou are half correct.\nlib/ contains modules *required* by gitweb\nmodules/ contains actions *performed* in gitweb like commitlog,\nsnapshot etc.. (write actions too)\n\nMaybe I will rename it to actions/ to not to be confused.\n\n>>>> The new script includes config and other basic files, checks\n>>>> the URL, parses it, detects the module, manage session and includes\n>>>> the proper module.\n>>>\n>>> O.K., so after splitting the main gitweb.perl file (from which\n>>> gitweb.cgi would be created during build) includes configuration\n>>> (hmmm... shouldn't default configuration and perhaps reading\n>>> site-specific configuration too be put into separate Perl module?),\n>>> dispatch (checking and parsing URL, verifying parameters, and\n>>> choosing action to run), and checking which extra modules (and\n>>> therefore which actions) are available.\n>>>\n>>> \"Manage session\"... err, current gitweb does not need session\n>>> management.  Would the \"write\" module require it, even if we can assume\n>>> that you are the only client like with git-instaweb, and authentication\n>>> is not required?  I would also recommend to not reinwent the wheel,\n>>> and if you feel that \"write\" module really needs session management,\n>>> use some existing CPAN module for it like e.g. CGI::Session, or at least\n>>> borrow (some) code from it.\n>>>\n>> I mean wouldn't using session be good thing to add. It doesn't need to use\n>> parameters like project name all the time in the URL.\n>\n> Using sessions is not without cost: you would (usually) need to store\n> extra information on the server.\n>\n> Also one usually wants for URLs to be bookmarkeable.  One would want\n> to be able to send link to be copy'n'pasted.\n>\n> If sessions are to make gitweb URLs shorter: forget it.  First, it would\n> be not necessary for your project.  Second, this is not the way to have\n> shorter URLs.\n>\n> See also the whole idea of stateless REST interface.\n\nYeah, we have already discussed about it in previous mails. The final\nconclusion is not to use session manager in gitweb. But let's include\na module for it so that it can be used when others build\nauthentication support.\n\n>>>> b) Write modules of the client:\n>>>>\n>>>>   1. Add existing repositories to the gitweb -- This will list the\n>>>>      given repo into gitweb config\n>>>\n>>> Note that if gitweb scans for repositories ($projects_list is\n>>> a directory, not a file with the list of projects), gitweb would detect\n>>> new repository automatically.  This feature (autodetecting\n>>> repositories) is fore example requirement on git.kernel.org.\n>>>\n>> Let us say if there are multiple repositories in multiple paths, wouldn't it\n>> be good to add a single project. This option will be available along with\n>> scanning $projects_root.\n>\n> If gitweb is configured to scan for repositories, adding existing git\n> repository to gitweb doesn't make sense.  If gitweb is configured to\n> use static file with list of repositories, of course it would make\n> sense... but then the question is how would one specify location of\n> a new repository to add.\n\nHow about like this ?\nWe will have a static file with list of projects. All the repositories\nin scan path will be added to this list. Then we will also have an\noption to add an existing repository which can be done when the user\nspecifies a relative or full path to the repository.\n\n>\n>>>>  12. Push to a remote branch [git push]\n>>>>  13. Fetch/Pull from a remote branch [git fetch | git pull]\n>>>\n>>> You would need support for either editing config, or for interface to\n>>> [git remote add] first, otherwise the only remote available would be\n>>> 'origin'.  Unless you are interested in pushing to / fetching from\n>>> repository given by URL...\n>>>\n>> I think i missed that point. all functionalites with \"git remote\" will be\n>> added too.\n>\n> Good.\n>\n>>>> d) Usage of the client:\n>>>>\n>>>> This client can be used in 2 ways.\n>>>>\n>>>> * Install a local version using instaweb - The gitweb will be only\n>>>> accessible by you. You can browse through the git repository using\n>>>> read modules and simultaneously work on them using write modules.\n>>>\n>>> This part could be doable during GSoC 2010 (if this project gets\n>>> accepted), I think.\n>>\n>> Yes. This is the main thing that is needed for a average git user.\n>\n> The main simplification is that we do not need authentication here,\n> only perhaps requirement that server is 'localhost'.\n\nYes, it wouldn't need authentication because the server will be localhost.\n\n>>>> * Install on intranet - A company when installs this gitweb along with\n>>>> some other login and account managing scripts will be able to order\n>>>> their employees to login and ask them to work on the code with out the\n>>>> security risk of providing ssh access to the git repository host.\n>>>> * Install on web - Just like normal gitweb, or enable write modules to\n>>>> look like gist.github.com\n>>>\n>>> This would require authentication support, which I think might be too\n>>> much for GSoC.\n>>\n>> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I\n>> hope to provide an authentication wrapper for gitweb in future.\n>\n> Well, unless there would be time for it after you finish all other work,\n> but it is a bit unlikely.\n\nI don't think so. I would like to constantly contribute to gitweb.\n\n>>>>    * Developing API to work with gitweb for storing information in\n>>>> form of a git repository\n>>>\n>>> What you mean by that?\n>>>\n>> I mean, I will be providing an web API wrapper for gitweb which can be used\n>> by other web developers to store any information they get into a git\n>> repository form and can use it to see the changes they made to the\n>> information step  by step.\n>\n> It doesn't tell me much either.  Do you mean some kind of REST API here,\n> to be used from other clients, or something like that?\n\nYes, Exactly.\n\n> Anyway I'd rather you put it in \"if I have time\" pile...\n\nYes, I already mentioned it in the proposal. It is under the section\n\"Future functionalities\"\n\n-pavan\n"},{"id":"139920","messageId":"j2ke72faaa81004191103qabe0c3ddj959d8804e873ed04@mail.gmail.com","threadId":"23468","inReplyTo":"20100419115113.GC3563@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T18:03:49Z","receivedAt":"2010-04-19T18:03:49Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Mon, Apr 19, 2010 at 5:21 PM, Petr Baudis wrote:\n> On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:\n>> On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:\n>> > If the project is a success, I wanted to use it for mob branch editing\n>> > on repo.or.cz. It could also be used as open-source Gist alternative.\n>>\n>> For that you would need editing file / editing contents action, but\n>> this is explicitely excluded in current version of Pavan's proposal :-(\n>\n> Is it? I see it only being omitted.\n\nYes, you can see it in \"future functionalities\" section of the proposal.\n\nImplementing a proper and perfect file editor will be a tough job. So,\nI removed it from GSoC and listed in that section.\nBut we can always have a simple textarea to implement it and I think I\nwill have time to do this simple textarea during my GSoC.\n\n>\n>> > But it needs to be coded so that it does not require an actual checked\n>> > out copy (which shouldn't be too much hassle).\n>>\n>> It would require using 'git hash-object -t blob -w --stdin' (from body\n>> submitted via POST from textarea) plus 'git update-index --cacheinfo'.\n>\n> Yes. Not a whole lot of effort, seems to me. A downside is that you\n> cannot use the working tree - index dichotomy, but life isn't perfect.\n>\n>> There is however complication that you would need to do open2/open3\n>> because git-hash-object would require bidirectional communication unless\n>> you would use temporary file (command_bidi_pipe in Git.pm, untested).\n>\n> I think even just going through a temporary file is fine for initial\n> implementation.\n>\n>> So additional step would be\n>>\n>>         cp -fvR gitweb/lib /var/www/cgi-bin/    ;# as root\n>\n> Yes!\n>\n>> I hope that we could make installing gitweb as easy as\n>>\n>>         make webscriptdir=/var/www/cgi-bin/ \\\n>>              gitweb-install\n>>\n\nWe can try it. :-)\n\n>> or in more complicated case (gitweb modules not installed in cgi-bin)\n>>\n>>         make webscriptdir=/var/www/cgi-bin/gitweb \\\n>>              GITWEB_BASE=\"/gitweb/\" \\\n>>              GITWEBPERLLIB=/usr/local/lib/perl5 \\\n>>              gitweb-install\n>>\n>> or something like that (I do not know any standard for the name of build\n>> configuration variable which tells where to install web aplication;\n>> do you?)\n>\n> Ideally, yes, but that's not directly tied to the splitting effort.\n> (No clue about the configuration variable.)\n>\n>> Well, I would perhaps start simply with\n>>\n>>   gitweb.perl\n>>   lib/Gitweb.pm\n>>\n>> We can modify file organization later; what's important is the build\n>> infrastructure (even if it is instruction in gitweb/INSTALL).\n>\n> That sounds like the best way. :)\n>\n> --\n>                                Petr \"Pasky\" Baudis\n> http://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n>\n"},{"id":"139921","messageId":"o2le72faaa81004191110t1da6c2f9i3f5f8491df7a2681@mail.gmail.com","threadId":"23468","inReplyTo":"20100419115727.GB10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-19T18:10:33Z","receivedAt":"2010-04-19T18:10:33Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"Sorry for late reply, I actually skipped this mail.\n\n2010/4/19 Petr Baudis :\n> On Mon, Apr 19, 2010 at 12:16:31PM +0530, Pavan Kumar Sunkara wrote:\n>> On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis wrote:\n>> > Frankly, I'm not very excited from this. First, I recommend that you\n>> > completely separate splitting of gitweb to smaller pieces (without any\n>> > major conceptual changes) both in the proposal and in actual\n>> > submissions.\n>> >\n>> > Second, you should justify the introduction of session management and\n>> > templating. What is the point and why is it neccessary for your project\n>> > goals?\n>> >\n>>\n>> Session management reduces the length of URL and templating reduces\n>> the amount of HTML in the actual code.\n>\n> ...which is bad?\n>\n> I don't see the value in session management; making the URL contain less\n> information is not _good_, it is _very_ _bad_, since you can't use the\n> Uniform Resource Locator to locate resources anymore.\n>\n> Introduction of templating would mean huge changes (not only addition of\n> the templater) for seemingly no warranted reason. I mean, if we were to\n> start writing gitweb from scratch, perhaps a templater engine *might*\n> warrant some consideration, but I don't see any itch we want to scratch\n> by introducing templating now. And no connectoin with the project at\n> hand.\n>\n>> >> b) Write modules of the client:\n>> >>  15. Search for a part of code [git grep]\n>> >\n>> > This is already supported by gitweb. And it's not a \"write\" operation.\n>> > ;-)\n>>\n>> I wrote it here because I would like to integrate it with content\n>> history browser functionality later.\n\nIf you remember, there is a gsoc idea named \"Content History Browser\"\nin ideas wiki page that is listed by you. It's about starting giddy\nfrom scratch to use pickaxe interface to see the history of a specific\ncontent. I would like to integrate this with that pickaxe interface.\n\n> I don't understand, can you elaborate?\n>\n>> >> c) Read modules of the client: (most of this need not be written, just\n>> >> need to be organised)\n>> >>\n>> >>   1. See the status of repository [git status]\n>> >\n>> > How will you integrate this with the existing 'tree' action?\n>>\n>> No, there will be a seperate page for it which executes git status command.\n>\n> And just passes through its plaintext output? Well, I suppose that could\n> do for starters.\n\nNo. It won't be just plain text. Every line will have links beside it\nto either stage or unstage or add or ignore or see diff for that file.\n\n>> > --\n>> >                                Petr \"Pasky\" Baudis\n>> > http://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n>> >\n>>\n>> Please ask me if you have any other doubts regarding this proposal.\n>\n> Could you clarify your attitude to the support for mode without checked\n> out working copy, using just the index, that we are discussing with\n> Jakub and I already mentioned to you in the past?\n\nYes, I remember it. TO be frank, I don't know the git commands to\nimplement this. So, If you can explain it to me more detailedly, Then\nI can implement it for sure.\n\n> --\n>                                Petr \"Pasky\" Baudis\n> http://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n>\n\nThanks\n-pavan\n"},{"id":"139940","messageId":"201004200114.07506.jnareb@gmail.com","threadId":"23468","inReplyTo":"u2ze72faaa81004191055t13ad6f2hbdcc319260cbabcf@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-19T23:14:05Z","receivedAt":"2010-04-19T23:14:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 19 April 2010, Pavan Kumar Sunkara wrote:\n> 2010/4/19 Jakub Narebski :\n>> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:\n>>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski wrote:\n\n>>>> First, a question: do you feel proficient enough in Perl (and in web\n>>>> scripting in Perl), or do you prefer other programming language for\n>>>> web, like e.g. Python?  If you feel like you would do better programming\n>>>> in Python (or PHP, or Ruby) rather than in Perl, you could write the\n>>>> main part of this GSoC project in said language, and provide only hooks\n>>>> into gitweb (with the help of developers on git mailing list).\n>>>\n>>> I don't know perl but learning it and becoming proficient in it won't be a\n>>> matter for me. I believe I am a fast learner and I am a computer science\n>>> student in the top university of India. I learnt python in an hour and\n>>> became proficient in it by a week. So learning perl won't be a matter for\n>>> me.\n>>\n>> I can agree that you would be able to learn Perl in a week.  I do not\n>> think however that you can become proficient in Perl (and neither in any\n>> other non-trivial programming language) in such short time.  The question\n>> remains if you can be proficient enough for the task in question...\n> \n> I can learn perl in 3 hours. Becoming proficient in perl is just\n> knowing about all the majorly used inbuilt functions and libraries.\n> Coming to the concepts of programming, I already know a lot about it\n> along with data structures and algortihms. So you need not doubt me on\n> this.\n\nYou can (probably) learn Perl *syntax* in 3 hours. You perhaps can\nlearn to start to write clean, idiomatic Perl within a week, provided\nthat you find good books (like \"Higher-Order Perl\", which can be found\nat http://hop.perl.plover.com/book/, or other Perl books from O'Reilly).\nBe proficient in Perl in that short time? I don't think so.\n\nI guess that you can learn enough Perl for this project, but I'd really\nprefer for you to be proficient in Perl already...\n \n>>>> \"It aims at developing functionalities for working on a git repository.\"\n>>>> Not only this is not grammatical, but also doesn't tell us the goal\n>>>> of your project.  Is it something to edit files and create commits via\n>>>> web, be to git-gui what git-instaweb is to gitk?  Is it about editing\n>>>> gitweb-specific configuration, like README/README.html and 'description'\n>>>> file from web browser?  Is it managing git repositories, i.e. create,\n>>>> fork or clone and mirror repositories, something that Gerrit does for\n>>>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?\n>>>>\n>>> I think you understood it from the later part of my proposal.\n>>\n>> Yes, I found it in later parts of proposal, but don't you think that\n>> this goal of this project should be stated upfront, so that one can\n>> know what this project is to be about from project description itself?\n> \n> I thought it should be described later in the \"Describe your project\n> in more detail\" section. So, I didn't go into details here.\n\nNevetheless it is a place to describe *specific* goal of project here,\nin one to two sentences. No marketing buzzwords here :-PPP\n \n[...]\n>>>>>    * modules (dir) -- directory containing the write and read modules.\n>>>>>    * lib (dir) -- some basic files like config, error_handler,\n>>>>> templater, redirecter, htmlHelper etc..\n>>>>\n>>>> I'm not sure about modules/ directory: wouldn't lib/ be enough?\n>>>> What needs to be in modules/ that cannot be put in lib/?\n>>\n>> I guess (please correct me if I am wrong) that lib/ would contain modules\n>> *required* by gitweb, and modules/ would contain *optional* modules\n>> needed for extra functionality (for extra features).\n> \n> You are half correct.\n> lib/ contains modules *required* by gitweb\n> modules/ contains actions *performed* in gitweb like commitlog,\n> snapshot etc.. (write actions too)\n> \n> Maybe I will rename it to actions/ to not to be confused.\n\nI don't understand why actions are not to be in lib/, like e.g. SVN::Web\n(http://p3rl.org/SVN::Web) has SVN::Web::Blame module for 'blame' action?\nAlthough I am not sure if SVN::Web is a good example of coding practices\nand code organization.\n\n>>>>>   1. Add existing repositories to the gitweb -- This will list the\n>>>>>      given repo into gitweb config\n>>>>\n>>>> Note that if gitweb scans for repositories ($projects_list is\n>>>> a directory, not a file with the list of projects), gitweb would detect\n>>>> new repository automatically.  This feature (autodetecting\n>>>> repositories) is fore example requirement on git.kernel.org.\n>>>>\n>>> Let us say if there are multiple repositories in multiple paths, wouldn't it\n>>> be good to add a single project. This option will be available along with\n>>> scanning $projects_root.\n>>\n>> If gitweb is configured to scan for repositories, adding existing git\n>> repository to gitweb doesn't make sense.  If gitweb is configured to\n>> use static file with list of repositories, of course it would make\n>> sense... but then the question is how would one specify location of\n>> a new repository to add.\n> \n> How about like this ?\n> We will have a static file with list of projects. All the repositories\n> in scan path will be added to this list. Then we will also have an\n> option to add an existing repository which can be done when the user\n> specifies a relative or full path to the repository.\n\nO.K. that is a good idea: make gitweb scan for repositories, and present\nuser with the list of them to add to static list of visible projects \n(repositories).\n\n>>> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I\n>>> hope to provide an authentication wrapper for gitweb in future.\n>>\n>> Well, unless there would be time for it after you finish all other work,\n>> but it is a bit unlikely.\n> \n> I don't think so. I would like to constantly contribute to gitweb.\n\nI'm sorry, we seem to have a bit of misunderstanding here. What I meant\nthat this should be in the \"optional\" part of GSoC project, so it would\nbe worked on during GSoC only after everything else is done. Because the\nscope of this project is quite wide, I though it unlikely to have time\nleft at the end of GSoC after finishing all other more important features.\n\nI did not mean to say that you would be unlikely to contribute after GSoC\nfinishes.\n \n-- \nJakub Narebski\nPoland\n"},{"id":"139965","messageId":"20100420114758.GO10939@machine.or.cz","threadId":"23468","inReplyTo":"o2le72faaa81004191110t1da6c2f9i3f5f8491df7a2681@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-20T11:47:58Z","receivedAt":"2010-04-20T11:47:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Apr 19, 2010 at 11:40:33PM +0530, Pavan Kumar Sunkara wrote:\n> 2010/4/19 Petr Baudis :\n> >> >> b) Write modules of the client:\n> >> >>  15. Search for a part of code [git grep]\n> >> >\n> >> > This is already supported by gitweb. And it's not a \"write\" operation.\n> >> > ;-)\n> >>\n> >> I wrote it here because I would like to integrate it with content\n> >> history browser functionality later.\n> \n> If you remember, there is a gsoc idea named \"Content History Browser\"\n> in ideas wiki page that is listed by you. It's about starting giddy\n> from scratch to use pickaxe interface to see the history of a specific\n> content. I would like to integrate this with that pickaxe interface.\n\nAha, I see. I will be curious what you come up with. :-)\n\n> >> No, there will be a seperate page for it which executes git status command.\n> >\n> > And just passes through its plaintext output? Well, I suppose that could\n> > do for starters.\n> \n> No. It won't be just plain text. Every line will have links beside it\n> to either stage or unstage or add or ignore or see diff for that file.\n\nOk!\n\n> > Could you clarify your attitude to the support for mode without checked\n> > out working copy, using just the index, that we are discussing with\n> > Jakub and I already mentioned to you in the past?\n> \n> Yes, I remember it. TO be frank, I don't know the git commands to\n> implement this. So, If you can explain it to me more detailedly, Then\n> I can implement it for sure.\n\nSee one of other Jakub's mails for examples of commands to be used.\nIf you have more specific questions, feel free to follow up.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139968","messageId":"20100420120731.GP10939@machine.or.cz","threadId":"23468","inReplyTo":"j2ke72faaa81004191103qabe0c3ddj959d8804e873ed04@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-20T12:07:31Z","receivedAt":"2010-04-20T12:07:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Apr 19, 2010 at 11:33:49PM +0530, Pavan Kumar Sunkara wrote:\n> Implementing a proper and perfect file editor will be a tough job. So,\n> I removed it from GSoC and listed in that section.\n> But we can always have a simple textarea to implement it and I think I\n> will have time to do this simple textarea during my GSoC.\n\nOf course we meant just plain textarea, I think that's more than enough.\nI think this would be rather important part of the project.\n\nFor later, there's also plenty of javascript editors available that can\nbe used as drop-ins, though I'm not sure if any of them is programming\noriented. At any rate, I don't see why text editor like this would be\ngitweb-specific.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"139969","messageId":"u2ke72faaa81004200517p6386438dt16fb0051584d5e18@mail.gmail.com","threadId":"23468","inReplyTo":"201004200114.07506.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-20T12:17:21Z","receivedAt":"2010-04-20T12:17:21Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Tue, Apr 20, 2010 at 4:44 AM, Jakub Narebski wrote:\n> On Mon, 19 April 2010, Pavan Kumar Sunkara wrote:\n>> 2010/4/19 Jakub Narebski :\n>>> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:\n>>>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski wrote:\n>\n>>>\n>>> I can agree that you would be able to learn Perl in a week.  I do not\n>>> think however that you can become proficient in Perl (and neither in any\n>>> other non-trivial programming language) in such short time.  The question\n>>> remains if you can be proficient enough for the task in question...\n>>\n>> I can learn perl in 3 hours. Becoming proficient in perl is just\n>> knowing about all the majorly used inbuilt functions and libraries.\n>> Coming to the concepts of programming, I already know a lot about it\n>> along with data structures and algortihms. So you need not doubt me on\n>> this.\n>\n> You can (probably) learn Perl *syntax* in 3 hours.  You perhaps can\n> learn to start to write clean, idiomatic Perl within a week, provided\n> that you find good books (like \"Higher-Order Perl\", which can be found\n> at http://hop.perl.plover.com/book/, or other Perl books from O'Reilly).\n> Be proficient in Perl in that short time?  I don't think so.\n>\n> I guess that you can learn enough Perl for this project, but I'd really\n> prefer for you to be proficient in Perl already...\n\nIt's your choice. All I can say is learning perl won't be a\nobstruction to do this project.\n\n>>>\n>>> Yes, I found it in later parts of proposal, but don't you think that\n>>> this goal of this project should be stated upfront, so that one can\n>>> know what this project is to be about from project description itself?\n>>\n>> I thought it should be described later in the \"Describe your project\n>> in more detail\" section.  So, I didn't go into details here.\n>\n> Nevetheless it is a place to describe *specific* goal of project here,\n> in one to two sentences.  No marketing buzzwords here :-PPP\n\n:-)\n\n>>>\n>>> I guess (please correct me if I am wrong) that lib/ would contain modules\n>>> *required* by gitweb, and modules/ would contain *optional* modules\n>>> needed for extra functionality (for extra features).\n>>\n>> You are half correct.\n>> lib/ contains modules *required* by gitweb\n>> modules/ contains actions *performed* in gitweb like commitlog,\n>> snapshot etc.. (write actions too)\n>>\n>> Maybe I will rename it to actions/ to not to be confused.\n>\n> I don't understand why actions are not to be in lib/, like e.g. SVN::Web\n> (http://p3rl.org/SVN::Web) has SVN::Web::Blame module for 'blame' action?\n> Although I am not sure if SVN::Web is a good example of coding practices\n> and code organization.\n\nI did so to make them clearly distinct and easily to be maintain and\nmodify later.\n\n>>>\n>>> If gitweb is configured to scan for repositories, adding existing git\n>>> repository to gitweb doesn't make sense.  If gitweb is configured to\n>>> use static file with list of repositories, of course it would make\n>>> sense... but then the question is how would one specify location of\n>>> a new repository to add.\n>>\n>> How about like this ?\n>> We will have a static file with list of projects. All the repositories\n>> in scan path will be added to this list. Then we will also have an\n>> option to add an existing repository which can be done when the user\n>> specifies a relative or full path to the repository.\n>\n> O.K. that is a good idea: make gitweb scan for repositories, and present\n> user with the list of them to add to static list of visible projects\n> (repositories).\n\nok.\n\n>>>\n>>> Well, unless there would be time for it after you finish all other work,\n>>> but it is a bit unlikely.\n>>\n>> I don't think so. I would like to constantly contribute to gitweb.\n>\n> I'm sorry, we seem to have a bit of misunderstanding here.  What I meant\n> that this should be in the \"optional\" part of GSoC project, so it would\n> be worked on during GSoC only after everything else is done.  Because the\n> scope of this project is quite wide, I though it unlikely to have time\n> left at the end of GSoC after finishing all other more important features.\n>\n> I did not mean to say that you would be unlikely to contribute after GSoC\n> finishes.\n\nok. I can include it is an option part of GSoC.\n\nThanks\n-pavan\n"},{"id":"139990","messageId":"201004202014.19477.jnareb@gmail.com","threadId":"23468","inReplyTo":"20100419115113.GC3563@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-20T18:14:15Z","receivedAt":"2010-04-20T18:14:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, Apr 19, 2010, Petr Baudis wrote:\n> On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:\n>> On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:\n\n>>> If the project is a success, I wanted to use it for mob branch editing\n>>> on repo.or.cz. It could also be used as open-source Gist alternative.\n>> \n>> For that you would need editing file / editing contents action, but\n>> this is explicitely excluded in current version of Pavan's proposal :-(\n> \n> Is it? I see it only being omitted.\n\nAt the end, in the section which describes what would be not included\nin the project, there was editing files excluded from project.\n\nWhich is a bit strange because you need some kind of web editor (even\nif it is simply textarea) for the commit message if this \"Web Client\"\nis to implement [git commit]...\n \n>>> But it needs to be coded so that it does not require an actual checked\n>>> out copy (which shouldn't be too much hassle).\n>> \n>> It would require using 'git hash-object -t blob -w --stdin' (from body\n>> submitted via POST from textarea) plus 'git update-index --cacheinfo'.\n> \n> Yes. Not a whole lot of effort, seems to me. A downside is that you\n> cannot use the working tree - index dichotomy, but life isn't perfect.\n\nWhat do you mean here by \"working tree - index dichotomy\"?\n \n>> There is however complication that you would need to do open2/open3\n>> because git-hash-object would require bidirectional communication unless\n>> you would use temporary file (command_bidi_pipe in Git.pm, untested).\n> \n> I think even just going through a temporary file is fine for initial\n> implementation.\n\nIt is not that difficult. You can use IPC::Open2 (which is in core)\nand IO::Handle (for easier coding; using IO::Handle is not strictly\nnecessary), like that:\n\n use IPC::Open2 qw(open2);\n use IO::Handle;\n\n ...\n\n my $pid = open2($out, $in, git_cmd(), 'hash-object', '-w', '--stdin');\n $in->printflush($cgi->param('textarea'))\n or die...;\n my $sha1 = $out->getline();\n chomp $sha1;\n\n close $out;\n waitpid $pid, 0;\n\nThen you would need:\n\n system(git_cmd(), 'update-index', '--cacheinfo',\n '100644', $sha1, $pretend_path)\n or die...;\n\nNot tested!\n-- \nJakub Narebski\nPoland\n"},{"id":"140051","messageId":"k2le72faaa81004211349o1628ed42s4fa0aa412006128@mail.gmail.com","threadId":"23468","inReplyTo":"201004202014.19477.jnareb@gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-21T20:49:02Z","receivedAt":"2010-04-21T20:49:02Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"Hi,\n According to advice from Christian and Petr, Here is my updated GSoC\nproposal which has been a result of all the discussions in this\nthread.\nThanks\n\n-pavan\n\n=====================================================\n\nSplitting gitweb and developing write functionalites\nStudent:        Pavan Kumar Sunkara\n\nThis project aims at splitting and organising the 6800 lines code of\ngitweb.pl into modules. Not only providing the browsing\nfunctionalities in gitweb, but it also aims at developing\nfunctionalities for working on a git repository.\n\n\nProject Goals\n\n1.What is the goal of your project?\nThe project goal is to try and implement write functionalities into\ngitweb to go along with it's browsing functionalities. Another goal is\nto split gitweb Perl script and reorganize its structure. I would like\nto split the gitweb script in such a way that, in the future others\nwill be able to develop more functionalities for gitweb (let it be\n'read' or 'write' actions) with the help of the framework like\nstructure of the new gitweb.\n\n'read' means browsing through the code and repository\n'write' means working on the code and repository.\n\nI will be describing about them detailedly in the later parts of the proposal.\n\n2.How would you measure its success or failure?\nThere are two parameters which would majorly determine the success or\nfailure of the project.\n\n   * Splitting gitweb such that there should be no problem with the\ninstallation of gitweb across cross servers and cross systems.\n   * Working with new addition to gitweb should be as easy as working\nwith other git GUIs (git commit tools)\n   * User friendly graphical interface with smart UI design\n\n3.Describe your project in more detail.\nI would like to split the currently 6800 long piece of code in\ngitweb.pl perl script into small files which will result in better\nreadability, maintainability and modifiability. The file structure of\nthe new gitweb is given below and I will explain the working after it.\n\n(From now on, I would like to call the actions of gitweb as modules of gitweb)\n\na) File Structure:\n\n   * gitweb.pl -- Main script parsing urls and calling required modules\n   * gitweb.css -- The style for the gitweb pages.\n   * gitweb.js -- javascript to make gitweb more interactive\n   * git-logo.png\n   * git-favicon.png\n   * Makefile --  Responsible for installing gitweb\n   * lib (dir) -- some basic files like config, view and other actions\n      * config.pm\n      * view.pm\n      * default.pm -- this just outputs the list of all projects.\n      * {actions}.pm -- One file for every action\n\nThe current gitweb makefile makes a gitweb.cgi from the perl script\nand requires a server for it's working. I would like to continue this\nprocess but the change will be in the gitweb perl script. The new\nscript includes config and other basic files, checks the URL, parses\nit, detects the action, uses the output and along with view.pm gives\nout a proper HTML, CSS web page. The lib directory will also contain\nsome basic modules like Gitweb::Repo, Gitweb::Commit which will make\ndeveloping further functionalities easier. The write actions need not\nbe working in a gitweb installation like repo.or.cz, so we will also\nhave an option to disable the write modules. I will be using a static\nfile to maintain the list of repositories which is obtained by\nscanning repositories.\n\nb) Read modules of the client: (most of this need not be written, just\nneed to be organised)\n\n  1. See the status of repository [git status]\n  2. Show diff of the current working file compared to HEAD [git diff]\n  3. List all the commits with pagination [git log]\n  4. With every commit we can\n         * Visualise trees [git ls-tree]\n         * Visualise files and diffs [git show]\n         * Visualise annotations [git blame]\n  5. List all branches including remote ones [git branch]\n  6. Search commits, branches, authors etc.. [git grep]\n\nc) Write modules of the client:\n\n  1. Add Existing repositories to the gitweb -- This will list the\ngiven repo into static list of repos.\n  2. Create new/Clone repositories into a given path [git init | git\nclone] -- This will create new repo and list it\n  3. Add/Remove/Move files [git add | git rm | git mv]\n  4. Stage/Unstage files [git add | git reset]\n  5. Add files to ignore list when u click on 'Ignore' link\n  6. Discard changes to a file in working copy [git reset]\n  7. Commit to the repository with a log message and an optional\nsign-off [git commit]\n  8. Manage branches [git branch]\n  9. A simple branch merging* [git merge]\n 10. Creating tags [git tag]\n 11. Implementing a simple file editor\n 12. Checkout code to a specific commit or branch or tag [git checkout]\n 13. Editing config for remotes [git remote]\n 14. Push to a remote branch [git push]\n 15. Fetch/Pull from a remote branch [git fetch | git pull]\n 16. Garbage collection [git gc | git count-objects | git fsck | git prune]\n 17. Search for a part of code using pickaxe\n\n* - Merging two branches can be quite complicated. Simple merge\nmentioned above will be just showing you that there are conflicts. But\nyou won't be having options to\n\nd) Usage of the client:\n\nThis client can be used in 2 ways.\n\n* Install a local version using instaweb - The gitweb will be only\naccessible by you. You can browse through the git repository using\nread modules and simultaneously work on them using write modules.\n* Install on intranet - A company when installs this gitweb along with\nsome other login and account managing scripts will be able to order\ntheir employees to login and ask them to work on the code with out the\nsecurity risk of providing ssh access to the git repository host. The\nauthentication support can be implemented as an optional part of my\nproposal.\n* Install on web - Just like normal gitweb, or enable write modules to\nlook like gist.github.com\n\ne) Future functionalities:\n\n   * Rebasing branches\n   * Content History browser using pickaxe\n   * Implementing git bisect\n   * Cherry picking\n   * Patches management along with email\n   * Viewing git stats in an interactive user interface\n   * Developing some kind of REST API to be used from other clients\nfor storing information in form of a git repository\n\nIf completed properly, this is going to be a combination of gitk,\ngit-gui and gitweb, giddy, git-age and other git tools into a great\ncode. Many of the current git users are dissatisfied with current git\nclients and have always been complaining about them in the IRC. Also\nsome of them complain about the complexity of installation of gitweb.\nThis project will solve both the problems.\n\nI don't know perl but I can learn it's syntax in less than a day and\nas I know the concepts of programming I will try to become proficient\nin perl starting from May 3rd.\n\nI will try to make sure that the patches to be as small as possible\nand easily reviewable. Also my vacation starts on May 2nd and ends on\nAugust 1st. So most of the project work will be done during the start\nof the GSoC project rather than in the end.\n\nI agree that as soon as the GSoC really starts, time for abstract\nplanning and discussing should be mostly over. I will be ready to\ncode, create patches, even if only RFC patches, send them to the list,\nand then discuss them, reply to reviews, improve them and resend and\ntry my best to merge them upstream.\n\nf) Sample Work - Mockup:\n\nA small pre-version smaple of the project can seen in my github\nrepository named 'gittor' here. It is written in python and just a\nsmall sampe of my work in write modules. This client is capable of\nbuilding any other functionality and can integrate the functionalities\nof any other git tools.\n\n\nTimeLine\n\nI strongly believe in Agile methodology and stick to it. Agile\npractices make all the more sense in open source projects like Git,\nwhere the features are added/modified on the basis of the user's\nfeedback. We should have the ability to swiftly modify the product or\nfeature on the basis of the feedback from the community.\n\nThe following gives a brief idea about the iteration cycle that I'll\nbe following during the development period: The iteration cycle is of\n1 day duration\n\n   * Discuss the deliverables for the next iteration with the mentors\nalong with my daily report.\n   * Work on the implementation and send patches on implemented\nfunctionality in email to developers mailing list.\n   * The developers and the mentors review it and try to merge it upstream\n   * Fix bugs, tweak UI etc depending on the feedback. Also document\neverything while its still fresh in my mind.\n\n[Prior May 24]\nRead and understand the code of current gitweb. Discuss with mentors\nand finish abstract planning.\n\n[May 4th week - June 1st week]\nSplit the whole code of gitweb into proposed structure and setup\nlibrary files along with installation and configuration.\n\n[June 2nd week]\nMove the read modules accordingly\n\n[June 3rd week]\nComplete module from W1 to W3\n\n[June 4th week]\nComplete modules from W4 to W7\n\n[July 1st week]\nComplete module W8 to W10\n\n[July 2nd week]\nCheck for any possible and potential security loopholes or bugs\n\n[July 3rd week]\nComplete modules W11 and W12\n\n[July 4th week]\nComplete modules W13 to W15\n\n[Aug 1st week]\nComplete mdoules W16 and W17\n\n[Aug 2nd week]\nScrub code, Improve Documentation and last minute touches\n\n-- W means write actions\n\n\nAbout Me\n\nI am an Indian student, doing my Bachelor's Degree in Computer Science\nand Engineering at IIT Madras, one of the top Universities in the\nWorld. I beleive I am a fast learner and have learnt most of the\nfamous programming languages in the coding world. I am 19 years old\nand have a keen interest in field of Game programming.\n\n1. Open Source Experience\n\nOpen Source Experience is one thing which everyone requires if he want\nto participate in Google Summer of Code. We need to have knowledge of\nversion control systems, such as SVN, GIT etc.. . Also they need to\nfollow the standard coding pratices and methods either given by the\nproject members or community. They should also be able to communicate\nwell. I believe I have all these mentioned qualities and have a keen\ninterest in field of Open Source programming.\n\n* LimeSurvey\nLimeSurvey is self-described as the 'leading open source tool for\nonline surveys', which probably isn't much of an exaggeration. I have\nalready submitted many patches for bugs and committed a few changes\nmyself\n\n* Charty - Google Wave Gadget\nIt is a Google Wave gadget for embedding interactive charts and\ngraphs. It uses methods like Google Wave API, XML, JSON and\njavascript. It's source is made open for all.\n\n* BBGFramework\nContributed to the open source PHP5 based Browser Based Gaming\nframework by adding installation package and fixing bugs.\n\n* Hackerz\nIt is an open source Hacking simulation game written in java and\ncurrently in very early stage with short source control history.\n\n2. Coding Expereince\n\nThere are more to my experience in programming than the ones listed in\nabove section. They all are in different languages of programming.\n\n* My Sport Club Manager - Browser Based Game\nIt is browser based Ice hockey simulation game that runs on PHP and\nmysql and uses other web technologies like AJAX and javascript\nlibraries like prototype. Designed a game flow and a database\nstructure and implemented the same. It offers a rich gameplay where\nclubs can be managed with parameters like stadium, tactics, formation,\nfinance, stats etc.. A runtime commentatory is genertated\nencapsulating all important movements of the game simulation.\n\n* Web related works\n     Created a PHP based file system Database and Query Language for\nsmall scale database applications.\n     Designed and developed a fully valid CSS for wordpress, the\nfamous blogging platform.\n     Developed a single page forum script to avoid space issues and\noptimized database calls to reduce the execution time unlike the\ntraditional bulky forums.\n     Incorporated a web-based application that offers flexibility in\npresentation of the information to generate a structured resume\nfollowing pre-defined document standards\n\n* Non-web related works\n     Designed and implemented an 8 bit micro-processor using Verilog, a HWDL\n     Developed an IRC bot for listening and logging a particular\nchannel given the required details.\n     Developed an AI for 'Dots and Boxes' game in Java.\n     Designed and developed a small TicTacToe Network game server and\nclient in Python\n\n3. Academic Experience\n\nI beleive I am a fast learner and have learnt most of the famous\nprogramming languages in the coding world. Some of the courses which\nare relevant to my GSoC project and proposal are:\n\n   * Data Structures and Algortihms\n   * Advanced Computer Programming\n   * Introduction to Computer Programming\n   * Basic Graph Theory\n\nThe other courses which I have taken and non-relevant to the project\nare Languages Machines and Computations, Switching Circuits and Logic\nDesign, Computer Architecture and Organisation.\n\nDifferent Programming languages which I am comfortable with:\n\n   * Python\n   * PHP\n   * SQL\n   * Javascript\n   * C\n   * C++\n   * Java\n   * Verilog\n   * Assembly language\n\nI believe in taking initiatives and executing them. I have a natural\naptitude for technology as demonstrated by my numerous innovative\nendeavors. I believe I am ambitious, creative and hardworking which\nmakes me an asset for any organization/team.\n\n4. Involvement with Git\n\nI use git for most of my projects and am fascinated by it's speed and\nuasbility. I think it is and is going to be the best content tracker\never known to the world.\n\nI have been subscribed to git mailing list for 2 months and have\nalready put one of my ideas forward to the git developers in the\nthread linked here\n\nI also submitted a patch which advices the users in git status to add\na file to gitignore if he want to ignore it permanently. It can seen\nin this mailing list thread here.\n"},{"id":"140154","messageId":"20100422202501.GJ10939@machine.or.cz","threadId":"23468","inReplyTo":"k2le72faaa81004211349o1628ed42s4fa0aa412006128@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-22T20:25:01Z","receivedAt":"2010-04-22T20:25:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi!\n\nOn Thu, Apr 22, 2010 at 02:19:02AM +0530, Pavan Kumar Sunkara wrote:\n> a) File Structure:\n> \n>    * gitweb.pl -- Main script parsing urls and calling required modules\n>    * gitweb.css -- The style for the gitweb pages.\n>    * gitweb.js -- javascript to make gitweb more interactive\n>    * git-logo.png\n>    * git-favicon.png\n>    * Makefile --  Responsible for installing gitweb\n>    * lib (dir) -- some basic files like config, view and other actions\n>       * config.pm\n>       * view.pm\n>       * default.pm -- this just outputs the list of all projects.\n>       * {actions}.pm -- One file for every action\n\n (I have reservations to this particular structure and naming, but I\ndon't think that's crucial for the proposal.)\n\n> The current gitweb makefile makes a gitweb.cgi from the perl script\n> and requires a server for it's working. I would like to continue this\n> process but the change will be in the gitweb perl script. The new\n> script includes config and other basic files, checks the URL, parses\n> it, detects the action, uses the output and along with view.pm gives\n> out a proper HTML, CSS web page.\n\nSounds fine in principle.\n\n> The lib directory will also contain\n> some basic modules like Gitweb::Repo, Gitweb::Commit which will make\n> developing further functionalities easier.\n\nBeware, this might be an awful can of worms. The previous gitweb SoC\nproject failed to get merged in part due to trying to do something like\nthis.\n\nI recommend to avoid any large architectural changes and just shuffle\naround all the utility routines to lib/Gitweb.pm or so.\n\n> I will be using a static\n> file to maintain the list of repositories which is obtained by\n> scanning repositories.\n\nWill this be compatible with the current project list file?\n\n> b) Read modules of the client: (most of this need not be written, just\n> need to be organised)\n> \n>   1. See the status of repository [git status]\n>   2. Show diff of the current working file compared to HEAD [git diff]\n>   3. List all the commits with pagination [git log]\n>   4. With every commit we can\n>          * Visualise trees [git ls-tree]\n>          * Visualise files and diffs [git show]\n>          * Visualise annotations [git blame]\n>   5. List all branches including remote ones [git branch]\n>   6. Search commits, branches, authors etc.. [git grep]\n> \n> c) Write modules of the client:\n> \n>   1. Add Existing repositories to the gitweb -- This will list the\n> given repo into static list of repos.\n>   2. Create new/Clone repositories into a given path [git init | git\n> clone] -- This will create new repo and list it\n>   3. Add/Remove/Move files [git add | git rm | git mv]\n>   4. Stage/Unstage files [git add | git reset]\n>   5. Add files to ignore list when u click on 'Ignore' link\n>   6. Discard changes to a file in working copy [git reset]\n>   7. Commit to the repository with a log message and an optional\n> sign-off [git commit]\n>   8. Manage branches [git branch]\n>   9. A simple branch merging* [git merge]\n>  10. Creating tags [git tag]\n>  11. Implementing a simple file editor\n>  12. Checkout code to a specific commit or branch or tag [git checkout]\n>  13. Editing config for remotes [git remote]\n>  14. Push to a remote branch [git push]\n>  15. Fetch/Pull from a remote branch [git fetch | git pull]\n>  16. Garbage collection [git gc | git count-objects | git fsck | git prune]\n>  17. Search for a part of code using pickaxe\n\nBTW, I think you could prioritize better, e.g. (5) or (10) is rather\nminor thing while (11) or (14),(15) are crucial. But this is not that\nimportant if you are confident you will finish everything listed. ;-)\n\n> * - Merging two branches can be quite complicated. Simple merge\n> mentioned above will be just showing you that there are conflicts. But\n> you won't be having options to\n\nBTW, I don't think it's really complicated at all in the simple conflict\ncase - just edit the file and do git add (getting all the file-directory\netc. cases right might be more tedious, but less important).\n\n> d) Usage of the client:\n> \n> This client can be used in 2 ways.\n> \n> * Install a local version using instaweb - The gitweb will be only\n> accessible by you. You can browse through the git repository using\n> read modules and simultaneously work on them using write modules.\n> * Install on intranet - A company when installs this gitweb along with\n> some other login and account managing scripts will be able to order\n> their employees to login and ask them to work on the code with out the\n> security risk of providing ssh access to the git repository host. The\n> authentication support can be implemented as an optional part of my\n> proposal.\n> * Install on web - Just like normal gitweb, or enable write modules to\n> look like gist.github.com\n\nNote that for the latter two, operation mode without working copy is\nessential; I have not seen you address it anywhere.\n\nGood work, I like this better than the first proposal. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"140163","messageId":"7vwrvz2npn.fsf@alter.siamese.dyndns.org","threadId":"23468","inReplyTo":"20100422202501.GJ10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-22T21:15:32Z","receivedAt":"2010-04-22T21:15:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n>> d) Usage of the client:\n>> \n>> This client can be used in 2 ways.\n>> \n>> * Install a local version using instaweb - The gitweb will be only\n>> accessible by you. You can browse through the git repository using\n>> read modules and simultaneously work on them using write modules.\n>> * Install on intranet - A company when installs this gitweb along with\n>> some other login and account managing scripts will be able to order\n>> their employees to login and ask them to work on the code with out the\n>> security risk of providing ssh access to the git repository host. The\n>> authentication support can be implemented as an optional part of my\n>> proposal.\n>> * Install on web - Just like normal gitweb, or enable write modules to\n>> look like gist.github.com\n>\n> Note that for the latter two, operation mode without working copy is\n> essential; I have not seen you address it anywhere.\n\nWhat do you mean by \"without working copy\"? Is the proposal about having\na working copy _per_ client on the server side, and the file editor and\ngoodies listed in the \"Wrote modules\" list operate on these files?\n\nPerhaps you meant to say \"without working copy on the client side\", and if\nthat is the case I think we are on the same wavelength. That is exactly\nwhy I earlier said that I imagine that the \"Gitweb client write support\"\nwould be based on something more standard like DeltaV, instead of rolling\na custom hack that is not compatible with anybody else.\n"},{"id":"140168","messageId":"x2xe72faaa81004221453t373c1d2atcea9e0119302b2f6@mail.gmail.com","threadId":"23468","inReplyTo":"20100422202501.GJ10939@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-22T21:53:42Z","receivedAt":"2010-04-22T21:53:42Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":">> The lib directory will also contain\n>> some basic modules like Gitweb::Repo, Gitweb::Commit which will make\n>> developing further functionalities easier.\n>\n> Beware, this might be an awful can of worms. The previous gitweb SoC\n> project failed to get merged in part due to trying to do something like\n> this.\n>\n> I recommend to avoid any large architectural changes and just shuffle\n> around all the utility routines to lib/Gitweb.pm or so.\n\nYeah sure.\n\n>> d) Usage of the client:\n>>\n>> This client can be used in 2 ways.\n>>\n>> * Install a local version using instaweb - The gitweb will be only\n>> accessible by you. You can browse through the git repository using\n>> read modules and simultaneously work on them using write modules.\n>> * Install on intranet - A company when installs this gitweb along with\n>> some other login and account managing scripts will be able to order\n>> their employees to login and ask them to work on the code with out the\n>> security risk of providing ssh access to the git repository host. The\n>> authentication support can be implemented as an optional part of my\n>> proposal.\n>> * Install on web - Just like normal gitweb, or enable write modules to\n>> look like gist.github.com\n>\n> Note that for the latter two, operation mode without working copy is\n> essential; I have not seen you address it anywhere.\n\nI am not planning to write the \"operation mode without working copy\"\nduring GSoC due to reasons I mentioned earlier. But I would like to\nadd it as an optional part for GSoC along with the authentication\nwrapper.\n\nSo, When I complete the main parts of my GSoC proposal, you will be\nable to use it in your localhost working on your local repos. If I\nhave time during GSoC I will complete the auth wrapper and \"without\nworking copy\" mode. Otherwise I will develop them after GSoC. Then you\ncan use the write functionalities in repo.or.cz without actual working\ncopies. :-)\n\nThanks\n-pavan\n"},{"id":"140186","messageId":"201004230727.52212.chriscool@tuxfamily.org","threadId":"23468","inReplyTo":"k2le72faaa81004211349o1628ed42s4fa0aa412006128@mail.gmail.com","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-04-23T05:27:52Z","receivedAt":"2010-04-23T05:27:52Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wednesday 21 April 2010 22:49:02 Pavan Kumar Sunkara wrote:\n> 1.What is the goal of your project?\n> The project goal is to try and implement write functionalities into gitweb\n> to go along with it's browsing functionalities. Another goal is to split\n> gitweb Perl script and reorganize its structure. I would like to split the\n> gitweb script in such a way that, in the future others will be able to\n> develop more functionalities for gitweb (let it be 'read' or 'write'\n> actions) with the help of the framework like structure of the new gitweb.\n> \n> 'read' means browsing through the code and repository\n> 'write' means working on the code and repository.\n> \n> I will be describing about them detailedly in the later parts of the\n> proposal.\n\nPerhaps this sentence could be worded like this:\n\n\"I will describe in detail the read and write actions in the later part of the \nproposal.\"\n \n> 2.How would you measure its success or failure?\n> There are two parameters which would majorly determine the success or\n> failure of the project.\n> \n> * Splitting gitweb such that there should be no problem with the\n> installation of gitweb across cross servers and cross systems.\n> * Working with new addition to gitweb should be as easy as working with\n> other git GUIs (git commit tools)\n> * User friendly graphical interface with smart UI design\n> \n> 3.Describe your project in more detail.\n> I would like to split the currently 6800 long piece of code in\n> gitweb.plperl script into small files which will result in better\n> readability,\n> maintainability and modifiability. The file structure of the new gitweb is\n> given below and I will explain the working after it.\n> \n> (From now on, I would like to call the actions of gitweb as modules of\n> gitweb)\n\nPerhaps it would be better to state that in the end each action will have its \nown Perl module.\n\nThough I agree with Petr that first you should probably just shuffle around all \nthe utility routines in one module and develop write actions in another module \nthat uses the first one.\n\nThanks,\nChristian.\n"},{"id":"140187","messageId":"w2qe72faaa81004222242rdc1b5ceaw71eaecaff0f6fc76@mail.gmail.com","threadId":"23468","inReplyTo":"201004230727.52212.chriscool@tuxfamily.org","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-23T05:42:01Z","receivedAt":"2010-04-23T05:42:01Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Fri, Apr 23, 2010 at 10:57 AM, Christian Couder\n wrote:\n> On Wednesday 21 April 2010 22:49:02 Pavan Kumar Sunkara wrote:\n>> 1.What is the goal of your project?\n>> The project goal is to try and implement write functionalities into gitweb\n>> to go along with it's browsing functionalities. Another goal is to split\n>> gitweb Perl script and reorganize its structure. I would like to split the\n>> gitweb script in such a way that, in the future others will be able to\n>> develop more functionalities for gitweb (let it be 'read' or 'write'\n>> actions) with the help of the framework like structure of the new gitweb.\n>>\n>> 'read' means browsing through the code and repository\n>> 'write' means working on the code and repository.\n>>\n>> I will be describing about them detailedly in the later parts of the\n>> proposal.\n>\n> Perhaps this sentence could be worded like this:\n>\n> \"I will describe in detail the read and write actions in the later part of the\n> proposal.\"\n>\n>> 2.How would you measure its success or failure?\n>> There are two parameters which would majorly determine the success or\n>> failure of the project.\n>>\n>>    * Splitting gitweb such that there should be no problem with the\n>> installation of gitweb across cross servers and cross systems.\n>>    * Working with new addition to gitweb should be as easy as working with\n>> other git GUIs (git commit tools)\n>>    * User friendly graphical interface with smart UI design\n>>\n>> 3.Describe your project in more detail.\n>> I would like to split the currently 6800 long piece of code in\n>> gitweb.plperl script into small files which will result in better\n>> readability,\n>> maintainability and modifiability. The file structure of the new gitweb is\n>> given below and I will explain the working after it.\n>>\n>> (From now on, I would like to call the actions of gitweb as modules of\n>> gitweb)\n>\n> Perhaps it would be better to state that in the end each action will have its\n> own Perl module.\n\nThanks. As I said before, Sorry for my grammar.\n\n> Though I agree with Petr that first you should probably just shuffle around all\n> the utility routines in one module and develop write actions in another module\n> that uses the first one.\n>\n> Thanks,\n> Christian.\n>\n>\n\nYeah, I am planning to do that. :-)\n\nThanks\n-pavan\n"},{"id":"140190","messageId":"20100423071014.GL3563@machine.or.cz","threadId":"23468","inReplyTo":"7vwrvz2npn.fsf@alter.siamese.dyndns.org","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-23T07:10:14Z","receivedAt":"2010-04-23T07:10:14Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Apr 22, 2010 at 02:15:32PM -0700, Junio C Hamano wrote:\n> Petr Baudis writes:\n> \n> > Note that for the latter two, operation mode without working copy is\n> > essential; I have not seen you address it anywhere.\n> \n> What do you mean by \"without working copy\"? Is the proposal about having\n> a working copy _per_ client on the server side, and the file editor and\n> goodies listed in the \"Wrote modules\" list operate on these files?\n\n Currently, the write side will probably not be able to work on bare\nrepositories; it will have a working copy _per repository_ and the\noperations like git add will work on the working copy.\n\n The original idea was to just have a git-gui replacement that runs\nwithin your browser, and that's what is getting implemented I think.\nThis is not that interesting to me, but the applications it can be\neasily extended to are. ;-)\n\n> Perhaps you meant to say \"without working copy on the client side\", and if\n> that is the case I think we are on the same wavelength. That is exactly\n> why I earlier said that I imagine that the \"Gitweb client write support\"\n> would be based on something more standard like DeltaV, instead of rolling\n> a custom hack that is not compatible with anybody else.\n\n DeltaV?\n\n I think WebDAV API would be very fine to have *in addition* to\nuser-friendly web interface, but is useful in very different scenarios.\nYou need something to frontend WebDAV anyway.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nhttp://pasky.or.cz/ | \"Ars longa, vita brevis.\" -- Hippocrates\n"},{"id":"140206","messageId":"7vsk6mzeny.fsf@alter.siamese.dyndns.org","threadId":"23468","inReplyTo":"20100423071014.GL3563@machine.or.cz","subject":"Re: GSoC 2010: \"Integrated Web Client for git\" proposal","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-23T09:44:33Z","receivedAt":"2010-04-23T09:44:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> The original idea was to just have a git-gui replacement that runs\n> within your browser, and that's what is getting implemented I think.\n\nOk.\n\n> I think WebDAV API would be very fine to have *in addition* to\n> user-friendly web interface, but is useful in very different scenarios.\n> You need something to frontend WebDAV anyway.\n\nThere are different \"useful\" projects that can happen in this area:\n\n - a project to create a general front-end to versioned WebDAV; or\n\n - a project to serve git repository to such front-end implementations; or\n\n - a project to build an ad-hoc \"git only\" system.\n\nThe first one doesn't have to be within the purview of the \"git\" project\nper-se, and it can presumably work against anybody's versioned WebDAV\nserver implementation (e.g. RFC 3253).\n\nThe second one would be to build one such server. It would be quite\nspecific to, hence suitable to be supported by, the \"git\" project.\n\nThe third? It may look like a simplest way to get a working system, but\nI see at least two downsides:\n\n - designing server-side working tree right is not trivial. I don't know\n if existing proposed standard matches the semantics git users expect\n from the versioning system well, but I would expect that it would be a\n far better starting point to use than coming up with a random ad-hoc\n semantics in a hurry.\n\n - in the end, the users will be tied to one implementation of the server\n and the client (they are pretty much the same single ball of wax under\n the current proposal, no?).\n\nYou can punt by choosing not to do a per-client server-side working tree\nand reduce the problem complexity somewhat, but at that point we will be\nlooking at a single-user ad-hoc system; it doesn't interest me very much,\npersonally [*1*].\n\n[Footnote]\n\n*1* It doesn't necessarily mean I'd vote the proposal down (git is not my\npersonal project)---it just means I wouldn't vote _for_ it.\n"}]}