GSoC 2010: "Integrated Web Client for git" proposal

> Hi!
> 
> Pavan Kumar Sunkara sent an email on the git mailing list a few days ago about 
> his GSoC proposal:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/144658/

> His proposal is based on the project he already started:
> 
> http://github.com/pkumar/gittor
> 
> There have been discussions about it on the GSoC web app and in some private 
> emails.
> 
> Possible GSoC mentors for this proposal don't want yet another web interface, 
> they want an existing interface to be improved on. As the obvious choice is to 
> improve gitweb, the current result from the discussions is that the proposal 
> should be changed so that the integrated web client is developed in Perl into 
> or alongside gitweb.

> 
> Pavan agreed to rewrite his proposal according to that and Petr and myself 
> volunteered to co-mentor him.
> 
> It was suggested that improving Gitalist 
> (http://wiki.catalystframework.org/wiki/gitalist) would be a better choice. 
> But this was rejected because Gitalist is too much different from gitweb so it 
> could not replace it for many people now using gitweb.

> Or is it
> meant as web analogue of git-gui: a committool, with ability to create
> new commits, perhaps to edit files (and add them, delete them, move them
> around), a bit like ikiwiki with Git backend, or other Git based wikis
> and blogs?

> 1. Keep "Web Client" separate for gitweb, and make use of gitweb 
>    hooks/plugin system like $feature{'actions'}.  This might require
>    adding new "hooks" to gitweb.
> 
>    The advantage is that "Web Client" can be written in any language,
>    not necessary Perl.  The disadvantage that if it is written in Perl,
>    some code might be duplicated.  It might be hard to write generic
>    hooks - the "Web Client" could be not as well integrated with gitweb.
> 
> 2. Write "Web Client" as a Perl module, like 'gitweb/cache.pm' in the
>    http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu
>    and 'require' this file as needed, guarded by global variable or
>    %feature.
> 
>    The advantage is possible tighter integration.  I am not sure about
>    being able to use code from gitweb in "Web Client".  It also requires
>    using Perl, and might require using some contortions if the problem
>    would be naturally split into multiple modules: there can be multiple
>    modules, but it could be better to have them in one file.

> > Or is it
> > meant as web analogue of git-gui: a committool, with ability to create
> > new commits, perhaps to edit files (and add them, delete them, move them
> > around), a bit like ikiwiki with Git backend, or other Git based wikis
> > and blogs?
> 
> Yes. Though it is probably supposed to be real Git frontend with Git
> semantics, not something more abstract with Git under the hood.

> > 1. Keep "Web Client" separate for gitweb, and make use of gitweb 
> >    hooks/plugin system like $feature{'actions'}.  This might require
> >    adding new "hooks" to gitweb.
> > 
> >    The advantage is that "Web Client" can be written in any language,
> >    not necessary Perl.  The disadvantage that if it is written in Perl,
> >    some code might be duplicated.  It might be hard to write generic
> >    hooks - the "Web Client" could be not as well integrated with gitweb.
> > 
> > 2. Write "Web Client" as a Perl module, like 'gitweb/cache.pm' in the
> >    http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu
> >    and 'require' this file as needed, guarded by global variable or
> >    %feature.
> > 
> >    The advantage is possible tighter integration.  I am not sure about
> >    being able to use code from gitweb in "Web Client".  It also requires
> >    using Perl, and might require using some contortions if the problem
> >    would be naturally split into multiple modules: there can be multiple
> >    modules, but it could be better to have them in one file.
> 
> I think (2) is only infinitesimally better than (1) if you can't call
> all the gitweb methods from your module anyway. For me, the main worry
> is maintaining some consistent UI for the user (graphical and URI-wise)
> and (2) can accomplish this really only in a limited way unless you go
> much further with the modularization first.

> > 3. Split Gitweb, add "Web Client" as one of modules.  Might be best
> >    from the purity point of view, but is practical only if it is
> >    integrated in gitweb.  That would require getting gitweb maintainer
> >    out of GSoC.   Also I am not sure how feaible this approach would be.
> 
> Would it be really required to get gitweb maintainer out of GSoC in
> order to go this way? Why?

> On Sun, Apr 18, Petr Baudis wrote:
> > On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
> 
> > > Or is it
> > > meant as web analogue of git-gui: a committool, with ability to create
> > > new commits, perhaps to edit files (and add them, delete them, move them
> > > around), a bit like ikiwiki with Git backend, or other Git based wikis
> > > and blogs?
> > 
> > Yes. Though it is probably supposed to be real Git frontend with Git
> > semantics, not something more abstract with Git under the hood.
> 
> Hmmm... doesn't look so easy.  What to do about simultaneous access
> (what webmin does?), and working directory (what ikiwiki does?)?

> > > 3. Split Gitweb, add "Web Client" as one of modules.  Might be best
> > >    from the purity point of view, but is practical only if it is
> > >    integrated in gitweb.  That would require getting gitweb maintainer
> > >    out of GSoC.   Also I am not sure how feaible this approach would be.
> > 
> > Would it be really required to get gitweb maintainer out of GSoC in
> > order to go this way? Why?
> 
> Well, at least someone who would be able to manage integrating split
> gitweb.  I think that splitting gitweb, and doing it well, is quite
> outside this GSoC 2010 proposal: it would be too much. 

> =====================================================
> 
> Splitting gitweb and developing write functionalites
> Student:        Pavan Kumar Sunkara
> 
> This project aims at splitting and organising the 6800 lines code of
> gitweb.pl into a nicely structured set of files. Not only providing
> the browsing functionalities in gitweb, but it also aims at developing
> functionalities for working on a git repository.

> 
> First I will describe my project goals, giving an overview of what I
> would like to contribute to git. Second I will give the proposed time
> line of the project which includes all the information about the
> project. Lastly I will give some information about myself.

> 
> Project Goals
> 
> 1. What is the goal of your project?
>
> The project goal is to try and implement write functionalities into

> 
> I would like to split the gitweb script in such a way that, in the
> future others will be able to develop more functionalities for gitweb
> (let it be 'read' or 'write' actions) with the help of the framework
> like structure of the new gitweb.

> 
> 2.How would you measure its success or failure?
>
> There are two parameters which would majorly determine the success or
> failure of the project.
> 
>    * Splitting gitweb such that there should be no problem with the
> installation of gitweb across cross servers and cross systems.

> 
> 3.Describe your project in more detail.
>
> I would like to split the currently 6800 long piece of code in
> gitweb.pl perl script into small files which will result in better
> readability, maintainability and modifiability. The file structure of
> the new gitweb is given below and I will explain the working after it.

> 
> a) File Structure:
> 
>    * gitweb.pl -- Main script parsing urls and calling required
>      modules

> 
> b) Write modules of the client:
> 
>   1. Add existing repositories to the gitweb -- This will list the
>      given repo into gitweb config

> 
> * - Merging two branches can be quite complicated
> 
> c) Read modules of the client: (most of this need not be written, just
> need to be organised)
> 
>   1. See the status of repository [git status]

> 
> d) Usage of the client:
> 
> This client can be used in 2 ways.
> 
> * Install a local version using instaweb - The gitweb will be only
> accessible by you. You can browse through the git repository using
> read modules and simultaneously work on them using write modules.

> * Install on intranet - A company when installs this gitweb along with
> some other login and account managing scripts will be able to order
> their employees to login and ask them to work on the code with out the
> security risk of providing ssh access to the git repository host.
> * Install on web - Just like normal gitweb, or enable write modules to
> look like gist.github.com

>    * Rebasing branches
>    * Content History browser - (The gsoc 2010 idea in wiki)
>    * Implementing git bisect
>    * Cherry picking
>    * Patches management along with email

> f) Sample Work - Mockup:
> 
> A small pre-version smaple of the project can seen in my github
> repository named 'gittor' here. It is written in python and just a
> small sampe of my work in write modules. This client is capable of
> building any other functionality and can integrate the functionalities
> of any other git tools.

> 3. Academic Experience
> 
> I beleive I am a fast learner and have learnt most of the famous
> programming languages in the coding world. Some of the courses which
> are relevant to my GSoC project and proposal are:
> 
>    * Data Structures and Algortihms
>    * Advanced Computer Programming
>    * Introduction to Computer Programming
> 
> The other courses which I have taken and non-relevant to the project
> are Languages Machines and Computations, Switching Circuits and Logic
> Design, Computer Architecture and Organisation.
> 
> Different Programming languages which I am comfortable with:
> 
>    * Python
>    * PHP
>    * SQL
>    * Javascript
>    * AJAX
>    * C
>    * C++
>    * HTML
>    * CSS
>    * Java
>    * Verilog
>    * Assembly language

> 4. Involvement with Git
> 
> I use git for most of my projects and am fascinated by it's speed and
> uasbility. I think it is and is going to be the best content tracker
> ever known to the world.
> 
> I have been subscribed to git mailing list for 2 months and have
> already put one of my ideas forward to the git developers in the
> thread linked here
> 
> I also submitted a patch which advices the users in git status to add
> a file to gitignore if he want to ignore it permanently. It can seen
> in this mailing list thread here.

> 2.How would you measure its success or failure?
> There are two parameters which would majorly determine the success or
> failure of the project.
> 
>    * Splitting gitweb such that there should be no problem with the
> installation of gitweb across cross servers and cross systems.

> 3.Describe your project in more detail.
> I would like to split the currently 6800 long piece of code in
> gitweb.pl perl script into small files which will result in better
> readability, maintainability and modifiability. The file structure of
> the new gitweb is given below and I will explain the working after it.
> 
> (From now on, I would like to call the actions of gitweb as modules of gitweb)
> 
> a) File Structure:
> 
>    * gitweb.pl -- Main script parsing urls and calling required modules
>    * gitweb.tpl -- The template of the web page (GUI) in which
> modules are embedded
>    * gitweb.css -- The style for the gitweb pages.
>    * gitweb.js -- javascript to make gitweb more interactive
>    * modules (dir) -- directory containing the write and read modules.
>    * lib (dir) -- some basic files like config, error_handler,
> templater, redirecter, htmlHelper etc..
> 
> The current gitweb makefile makes a gitweb.cgi from the perl script
> and requires apache or lighttpd server for it's working. I would like
> to continue this process but the change will be in the gitweb perl
> script. The new script includes config and other basic files, checks
> the URL, parses it, detects the module, manage session and includes
> the proper module. It then retreives the output of the module and
> substitutes it with the gitweb.tpl template file string and gives out
> a proper HTML, CSS web page. It also contains some basic library files
> in the lib directory. The new gitweb uses session variables to track
> some of the variables rather than including them in the url. The write
> modules need not be working in a gitweb installation like repo.or.cz,
> so we will also have an option to disable the write modules.

> b) Write modules of the client:
> 
>   1. Add Existing repositories to the gitweb -- This will list the
> given repo into gitweb config
>   2. Create new/Clone repositories into a given path [git init | git
> clone] -- This will create new repo and list it
>   3. Add/Remove/Move files [git add | git rm | git mv]
>   4. Stage/Unstage files [git add | git reset]
>   5. Add files to ignore list when u click on 'Ignore' link
>   6. Discard changes to a file in working copy [git reset]
>   7. Commit to the repository with a log message and an optional
> sign-off [git commit]
>   8. Switch branches [git branch]
>   9. A simple branch merging* [git merge]
>  10. Creating tags [git tag]
>  11. Checkout code to a specific commit or branch or tag [git checkout]
>  12. Push to a remote branch [git push]
>  13. Fetch/Pull from a remote branch [git fetch | git pull]
>  14. Garbage collection [git gc]

>   4. With every commit we can
>          * Visualise trees [git ls-tree]
>          * Visualise files and diffs [git show]
>          * Visualise annotations [git blame]
>   5. List all branches including remote ones [git branch]
>   6. Search commits, branches, authors etc..

> d) Usage of the client:
> * Install on intranet - A company when installs this gitweb along with
> some other login and account managing scripts will be able to order
> their employees to login and ask them to work on the code with out the
> security risk of providing ssh access to the git repository host.

> Thanks for work on the proposal!
>
> On Sun, Apr 18, 2010 at 02:22:20PM +0530, Pavan Kumar Sunkara wrote:
>> 2.How would you measure its success or failure?
>> There are two parameters which would majorly determine the success or
>> failure of the project.
>>
>>    * Splitting gitweb such that there should be no problem with the
>> installation of gitweb across cross servers and cross systems.
>
> I believe an important factor in the success of the project is getting
> these changes merged upstream in the main Git branch.
>
> If the rest of the project features is not merged (and it *won't* be for
> the lack of trying), it will still be reasonably easy to use it as a
> third-party modification. However, if the split-up itself will not be
> merged, that will have big impact on the usefulness of the whole project
> - so I consider this fairly crucial, please don't under-estimate this
> part, getting things merged can take as much work as doing initial
> implementation of the stuff! You should plan to submit these patches
> quite early.

>>    * It should be possible that the new gitweb requires less time to
>> work on a git repository than any other git client.
>
> I'm sorry, I don't understand this.
>
>> 3.Describe your project in more detail.
>> I would like to split the currently 6800 long piece of code in
>> gitweb.pl perl script into small files which will result in better
>> readability, maintainability and modifiability. The file structure of
>> the new gitweb is given below and I will explain the working after it.
>>
>> (From now on, I would like to call the actions of gitweb as modules of gitweb)
>>
>> a) File Structure:
>>
>>    * gitweb.pl -- Main script parsing urls and calling required modules
>>    * gitweb.tpl -- The template of the web page (GUI) in which
>> modules are embedded
>>    * gitweb.css -- The style for the gitweb pages.
>>    * gitweb.js -- javascript to make gitweb more interactive
>>    * modules (dir) -- directory containing the write and read modules.
>>    * lib (dir) -- some basic files like config, error_handler,
>> templater, redirecter, htmlHelper etc..
>>
>> The current gitweb makefile makes a gitweb.cgi from the perl script
>> and requires apache or lighttpd server for it's working. I would like
>> to continue this process but the change will be in the gitweb perl
>> script. The new script includes config and other basic files, checks
>> the URL, parses it, detects the module, manage session and includes
>> the proper module. It then retreives the output of the module and
>> substitutes it with the gitweb.tpl template file string and gives out
>> a proper HTML, CSS web page. It also contains some basic library files
>> in the lib directory. The new gitweb uses session variables to track
>> some of the variables rather than including them in the url. The write
>> modules need not be working in a gitweb installation like repo.or.cz,
>> so we will also have an option to disable the write modules.
>
> Frankly, I'm not very excited from this. First, I recommend that you
> completely separate splitting of gitweb to smaller pieces (without any
> major conceptual changes) both in the proposal and in actual
> submissions.
>
> Second, you should justify the introduction of session management and
> templating. What is the point and why is it neccessary for your project
> goals?
>

>> b) Write modules of the client:
>>
>>   1. Add Existing repositories to the gitweb -- This will list the
>> given repo into gitweb config
>>   2. Create new/Clone repositories into a given path [git init | git
>> clone] -- This will create new repo and list it
>>   3. Add/Remove/Move files [git add | git rm | git mv]
>>   4. Stage/Unstage files [git add | git reset]
>>   5. Add files to ignore list when u click on 'Ignore' link
>>   6. Discard changes to a file in working copy [git reset]
>>   7. Commit to the repository with a log message and an optional
>> sign-off [git commit]
>>   8. Switch branches [git branch]
>>   9. A simple branch merging* [git merge]
>>  10. Creating tags [git tag]
>>  11. Checkout code to a specific commit or branch or tag [git checkout]
>>  12. Push to a remote branch [git push]
>>  13. Fetch/Pull from a remote branch [git fetch | git pull]
>>  14. Garbage collection [git gc]
>
> Sounds reasonable. What am I missing is a way to edit files through the
> web interface. Also, please spec in more detail the difference between
> [8] and [11].

>
>>  15. Search for a part of code [git grep]
>
> This is already supported by gitweb. And it's not a "write" operation.
> ;-)

>> c) Read modules of the client: (most of this need not be written, just
>> need to be organised)
>>
>>   1. See the status of repository [git status]
>
> How will you integrate this with the existing 'tree' action?

>
>>   4. With every commit we can
>>          * Visualise trees [git ls-tree]
>>          * Visualise files and diffs [git show]
>>          * Visualise annotations [git blame]
>>   5. List all branches including remote ones [git branch]
>>   6. Search commits, branches, authors etc..
>
> I.e. what we already do?

>
>> d) Usage of the client:
>> * Install on intranet - A company when installs this gitweb along with
>> some other login and account managing scripts will be able to order
>> their employees to login and ask them to work on the code with out the
>> security risk of providing ssh access to the git repository host.
>
> Frankly, the net security risk of providing git-shell access is probably
> lower than using a web interface. ;-) However, I still see this making
> many corporate people happy and opening doors to less canonical Git
> usecases - it also enables "zero config" ability to contribute to Git
> projects, desirable for less technical users (artists etc.).

>> I will try to make sure that the patches to be as small as possible
>> and easily reviewable. Also my vacation starts on May 2nd and ends on
>> August 1st. So most of the project work will be done during the start
>> of the GSoC project rather than in the end.
>
> Great!
>
>> [May 4th week - June 1st week]
>> Split the whole code of gitweb into framework structure and setup
>> library files along with installation and configuration.
>
> I think this might end up being rather tricky, and would appreciate you
> detailing this out a bit more, including some expected dates for initial
> patch submissions.

>
>> [July 2nd week]
>> Check for any possible and potential security loopholes or bugs
>
> I appreciate that you are thinking about this, though I'm less sure if
> this can be efficiently done as a batch job like this.
>

> Pavan Kumar Sunkara <pavan.sss1991@gmail.com> writes:
>
>> Session management reduces the length of URL
>
> ... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
> which is in my opinion a must-have for gitweb.

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Pavan Kumar Sunkara <pavan.sss1991@gmail.com> writes:
>>
>>> Session management reduces the length of URL
>>
>> ... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
>> which is in my opinion a must-have for gitweb.
>
> These self-contained URL are used in bookmarks and e-mails to the mailing
> list.  I think "the length of URL" is a red herring at best, and shortened
> URL that is not self-contained is not an advantage at all.

> When I heard that somebody wants to do a "write support" in gitweb, I
> naturally thought the proposal was about implementing RFC3253 using git as
> a backend.  I think it would be a reasonable thing to do (as opposed to
> coming up with an ad-hoc "write support" mechanism that is not compatible
> with anybody else), but on the other hand it might be a bit too ambitious
> for a one-student summer project.
>

> On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > On the other hand, a proposal about giving multiple clients access to
> > their own individual server-side checkouts (ala "workspace" in DELTA-V)
> > would require some mechanism to maintain the state on the server end, and
> > session management would be one ingredient necessary to achieve that.

> So, why don't we do like this,
> There will be no need of session management when gitweb is installed
> in some site like repo.or.cz which needs copy'n'paste URLs
> but there will be session management when the write modules are
> enabled and when gitweb is installed locally or on intranet (basically
> when it is used to work on a repo).
> 
> What do you say ?

> > When I heard that somebody wants to do a "write support" in gitweb, I
> > naturally thought the proposal was about implementing RFC3253 using git as
> > a backend.  I think it would be a reasonable thing to do (as opposed to
> > coming up with an ad-hoc "write support" mechanism that is not compatible
> > with anybody else), but on the other hand it might be a bit too ambitious
> > for a one-student summer project.

> On Mon, Apr 19, 2010 at 01:08:26PM +0530, Pavan Kumar Sunkara wrote:
>> On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > On the other hand, a proposal about giving multiple clients access to
>> > their own individual server-side checkouts (ala "workspace" in DELTA-V)
>> > would require some mechanism to maintain the state on the server end, and
>> > session management would be one ingredient necessary to achieve that.
>
> But what if I will want to give a link to my "workspace" to someone
> else? You can embed workspace id in the URL, in fact you would probably
> just use it instead of project name completely naturally. I still don't
> see any need for sessions.

> All of us are supporting using GET parameters rather than sessions for
> project name and others which is fine for me as the reasons are valid.
> But I would like to develop sessions manager incase they want to use
> authentication support.
>
> What do you say ?

> On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis <pasky@suse.cz> wrote:
> > Frankly, I'm not very excited from this. First, I recommend that you
> > completely separate splitting of gitweb to smaller pieces (without any
> > major conceptual changes) both in the proposal and in actual
> > submissions.
> >
> > Second, you should justify the introduction of session management and
> > templating. What is the point and why is it neccessary for your project
> > goals?
> >
> 
> Session management reduces the length of URL and templating reduces
> the amount of HTML in the actual code.

> >> b) Write modules of the client:
> >>  15. Search for a part of code [git grep]
> >
> > This is already supported by gitweb. And it's not a "write" operation.
> > ;-)
> 
> I wrote it here because I would like to integrate it with content
> history browser functionality later.

> >> c) Read modules of the client: (most of this need not be written, just
> >> need to be organised)
> >>
> >>   1. See the status of repository [git status]
> >
> > How will you integrate this with the existing 'tree' action?
> 
> No, there will be a seperate page for it which executes git status command.

> > --
> >                                Petr "Pasky" Baudis
> > http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
> >
> 
> Please ask me if you have any other doubts regarding this proposal.

> On Mon, Apr 19, 2010 at 12:16:31PM +0530, Pavan Kumar Sunkara wrote:
>> On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis <pasky@suse.cz> wrote:
>> > Frankly, I'm not very excited from this. First, I recommend that you
>> > completely separate splitting of gitweb to smaller pieces (without any
>> > major conceptual changes) both in the proposal and in actual
>> > submissions.
>> >
>> > Second, you should justify the introduction of session management and
>> > templating. What is the point and why is it neccessary for your project
>> > goals?
>> >
>>
>> Session management reduces the length of URL and templating reduces
>> the amount of HTML in the actual code.
>
> ...which is bad?
>
> I don't see the value in session management; making the URL contain less
> information is not _good_, it is _very_ _bad_, since you can't use the
> Uniform Resource Locator to locate resources anymore.
>
> Introduction of templating would mean huge changes (not only addition of
> the templater) for seemingly no warranted reason. I mean, if we were to
> start writing gitweb from scratch, perhaps a templater engine *might*
> warrant some consideration, but I don't see any itch we want to scratch
> by introducing templating now. And no connectoin with the project at
> hand.
>
>> >> b) Write modules of the client:
>> >>  15. Search for a part of code [git grep]
>> >
>> > This is already supported by gitweb. And it's not a "write" operation.
>> > ;-)
>>
>> I wrote it here because I would like to integrate it with content
>> history browser functionality later.

> I don't understand, can you elaborate?
>
>> >> c) Read modules of the client: (most of this need not be written, just
>> >> need to be organised)
>> >>
>> >>   1. See the status of repository [git status]
>> >
>> > How will you integrate this with the existing 'tree' action?
>>
>> No, there will be a seperate page for it which executes git status command.
>
> And just passes through its plaintext output? Well, I suppose that could
> do for starters.

>> > --
>> >                                Petr "Pasky" Baudis
>> > http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
>> >
>>
>> Please ask me if you have any other doubts regarding this proposal.
>
> Could you clarify your attitude to the support for mode without checked
> out working copy, using just the index, that we are discussing with
> Jakub and I already mentioned to you in the past?

> 2010/4/19 Petr Baudis <pasky@suse.cz>:
> >> >> b) Write modules of the client:
> >> >>  15. Search for a part of code [git grep]
> >> >
> >> > This is already supported by gitweb. And it's not a "write" operation.
> >> > ;-)
> >>
> >> I wrote it here because I would like to integrate it with content
> >> history browser functionality later.
> 
> If you remember, there is a gsoc idea named "Content History Browser"
> in ideas wiki page that is listed by you. It's about starting giddy
> from scratch to use pickaxe interface to see the history of a specific
> content. I would like to integrate this with that pickaxe interface.

> >> No, there will be a seperate page for it which executes git status command.
> >
> > And just passes through its plaintext output? Well, I suppose that could
> > do for starters.
> 
> No. It won't be just plain text. Every line will have links beside it
> to either stage or unstage or add or ignore or see diff for that file.

> > Could you clarify your attitude to the support for mode without checked
> > out working copy, using just the index, that we are discussing with
> > Jakub and I already mentioned to you in the past?
> 
> Yes, I remember it. TO be frank, I don't know the git commands to
> implement this. So, If you can explain it to me more detailedly, Then
> I can implement it for sure.

>>>> Or is it
>>>> meant as web analogue of git-gui: a committool, with ability to create
>>>> new commits, perhaps to edit files (and add them, delete them, move them
>>>> around), a bit like ikiwiki with Git backend, or other Git based wikis
>>>> and blogs?
>>> 
>>> Yes. Though it is probably supposed to be real Git frontend with Git
>>> semantics, not something more abstract with Git under the hood.
>> 
>> Hmmm... doesn't look so easy.  What to do about simultaneous access
>> (what webmin does?), and working directory (what ikiwiki does?)?
> 
>   I would expect it to work the same as if you work in single working
> copy from multiple shells. If multiple people want to collaborate, each
> should have their own clone to begin with.

>> Well, you can always add some of "Web Client" functionality directly
>> to gitweb (for example dispatch must be, I think, in gitweb).
> 
> But I don't think you can reasonably separate a major portion of web
> client that would not depend on gitweb functions like href(), format*()
> etc. all over the map.

>> Or you
>> can (ab)use "do $gitwebgui_pm;" instead of "require $gitwebgui_pm;",
>> like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3
>> (second chunk).
> 
> This already occured to me, yes. It's tempting to have this as the
> emergency way out, shall other things fail. But .

>> OTOH we can always make gitweb "use Git;" and move some of its routines,
>> to it after generalization (e.g. config management using single run of
>> "git config -l -z", unquoting paths, parsing commit/tag/ls-tree/difftree
>> etc., date parsing and conversion).
> 
> Yes, but not things like href(), git_header_html() and other absolutely
> essential routines.

>>>> 3. Split Gitweb, add "Web Client" as one of modules.  Might be best
>>>>    from the purity point of view, but is practical only if it is
>>>>    integrated in gitweb.  That would require getting gitweb maintainer
>>>>    out of GSoC.   Also I am not sure how feaible this approach would be.
>>> 
>>> Would it be really required to get gitweb maintainer out of GSoC in
>>> order to go this way? Why?
>> 
>> Well, at least someone who would be able to manage integrating split
>> gitweb.  I think that splitting gitweb, and doing it well, is quite
>> outside this GSoC 2010 proposal: it would be too much. 
> 
> This was my hesitation at the beginning, but I'm not really sure if
> it's really so hard, _if_ we resist the temptation to snowball unrelated
> cleanups on top of it. Conceptually, it isn't really hard to do, is it?
> The only tricky thing would be making sure instaweb still works and
> installation is still easy, but I don't see anything really difficult in
> this area either...?

> >> Well, you can always add some of "Web Client" functionality directly
> >> to gitweb (for example dispatch must be, I think, in gitweb).
> > 
> > But I don't think you can reasonably separate a major portion of web
> > client that would not depend on gitweb functions like href(), format*()
> > etc. all over the map.
> 
> Well, there is also copy'n'paste of code as a last resort.  

> >> Or you
> >> can (ab)use "do $gitwebgui_pm;" instead of "require $gitwebgui_pm;",
> >> like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3
> >> (second chunk).
> > 
> > This already occured to me, yes. It's tempting to have this as the
> > emergency way out, shall other things fail. But .
>                                               ^^^^^^^^^^-- ???
> But what?
> 
> Yes, it is not as elegant as "require", and you have to catch errors
> in "do"-ed file yourself (as described at the end of `perldoc -f do`).

> Also there is a question _how_ to split gitweb into modules, 
> e.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should
> be split.  But I guess any splitting would suffice; we need to provide
> a way to build and install split gitweb.  
> 
> Split can be as simple as:
> 
>   Makefile, or Makefile.PL, or Build.PL
>   gitweb.perl
>   static/git-logo.png
>   static/git-favicon.png
>   static/gitweb.css
>   static/gitweb.js
>   lib/Gitweb/Utils.pm   (Gitweb::Utils)
>   lib/Gitweb/Editor.pm  (Gitweb::Editor, for GSoC2010, if it gets accepted)

>> So it is intended, I guess, more like git-instaweb or webmin, not like
>> administrative parts of Girocco (or repo.or.cz), GitHub, Gitorious or
>> InDefero.  Probably authentication and authorization would not be needed
>> then, if it is to be run as web interface but locally...
> 
> If the project is a success, I wanted to use it for mob branch editing
> on repo.or.cz. It could also be used as open-source Gist alternative.

>> Currently to install gitweb you have to copy *one* script, and a few
>> static files (2 x image, CSS, JavaScript).  You can configure it using
>> "make gitweb" with appropriate options, you can simply edit gitweb script,
>> or you can leave this to the gitweb config file.
> 
> I don't really think things can get *any* more complicated than "also
> copy over this directory recursively", do they?

>> Also there is a question _how_ to split gitweb into modules, 
>> e.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should
>> be split.  But I guess any splitting would suffice; we need to provide
>> a way to build and install split gitweb.  
>> 
>> Split can be as simple as:
>> 
>>   Makefile, or Makefile.PL, or Build.PL
>>   gitweb.perl
>>   static/git-logo.png
>>   static/git-favicon.png
>>   static/gitweb.css
>>   static/gitweb.js
>>   lib/Gitweb/Utils.pm   (Gitweb::Utils)
>>   lib/Gitweb/Editor.pm  (Gitweb::Editor, for GSoC2010, if it gets accepted)
> 
> Exactly! I think we can do this reasonably incrementally; if something
> is not working out, we can move it again later. Let's not overengineer
> stuff. I think it would make sense to just split out something like
> Gitweb::Git (for Git invocations), Gitweb::CGI (for CGI parsing and
> HTML output toolkit) and perhaps Gitweb::Util for misc. stuff. Then,
> if we feel like it, maybe we can start splitting out things more, like
> Gitweb::CGI::Blame, but I don't think that's even neccessary for now.

> On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:
> > If the project is a success, I wanted to use it for mob branch editing
> > on repo.or.cz. It could also be used as open-source Gist alternative.
> 
> For that you would need editing file / editing contents action, but
> this is explicitely excluded in current version of Pavan's proposal :-(

> > But it needs to be coded so that it does not require an actual checked
> > out copy (which shouldn't be too much hassle).
> 
> It would require using 'git hash-object -t blob -w --stdin' (from body
> submitted via POST from textarea) plus 'git update-index --cacheinfo'.

> I hope that we could make installing gitweb as easy as
> 
>         make webscriptdir=/var/www/cgi-bin/ \
>              gitweb-install
>  
> or in more complicated case (gitweb modules not installed in cgi-bin)
> 
>         make webscriptdir=/var/www/cgi-bin/gitweb \
>              GITWEB_BASE="/gitweb/" \
>              GITWEBPERLLIB=/usr/local/lib/perl5 \
>              gitweb-install
> 
> or something like that (I do not know any standard for the name of build
> configuration variable which tells where to install web aplication; 
> do you?)

> Well, I would perhaps start simply with 
> 
>   gitweb.perl
>   lib/Gitweb.pm
> 
> We can modify file organization later; what's important is the build
> infrastructure (even if it is instruction in gitweb/INSTALL).

> On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:
>> On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:
>> > If the project is a success, I wanted to use it for mob branch editing
>> > on repo.or.cz. It could also be used as open-source Gist alternative.
>>
>> For that you would need editing file / editing contents action, but
>> this is explicitely excluded in current version of Pavan's proposal :-(
>
> Is it? I see it only being omitted.

>
>> > But it needs to be coded so that it does not require an actual checked
>> > out copy (which shouldn't be too much hassle).
>>
>> It would require using 'git hash-object -t blob -w --stdin' (from body
>> submitted via POST from textarea) plus 'git update-index --cacheinfo'.
>
> Yes. Not a whole lot of effort, seems to me. A downside is that you
> cannot use the working tree - index dichotomy, but life isn't perfect.
>
>> There is however complication that you would need to do open2/open3
>> because git-hash-object would require bidirectional communication unless
>> you would use temporary file (command_bidi_pipe in Git.pm, untested).
>
> I think even just going through a temporary file is fine for initial
> implementation.
>
>> So additional step would be
>>
>>         cp -fvR gitweb/lib /var/www/cgi-bin/    ;# as root
>
> Yes!
>
>> I hope that we could make installing gitweb as easy as
>>
>>         make webscriptdir=/var/www/cgi-bin/ \
>>              gitweb-install
>>

>> or in more complicated case (gitweb modules not installed in cgi-bin)
>>
>>         make webscriptdir=/var/www/cgi-bin/gitweb \
>>              GITWEB_BASE="/gitweb/" \
>>              GITWEBPERLLIB=/usr/local/lib/perl5 \
>>              gitweb-install
>>
>> or something like that (I do not know any standard for the name of build
>> configuration variable which tells where to install web aplication;
>> do you?)
>
> Ideally, yes, but that's not directly tied to the splitting effort.
> (No clue about the configuration variable.)
>
>> Well, I would perhaps start simply with
>>
>>   gitweb.perl
>>   lib/Gitweb.pm
>>
>> We can modify file organization later; what's important is the build
>> infrastructure (even if it is instruction in gitweb/INSTALL).
>
> That sounds like the best way. :)
>
> --
>                                Petr "Pasky" Baudis
> http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
>

>>> If the project is a success, I wanted to use it for mob branch editing
>>> on repo.or.cz. It could also be used as open-source Gist alternative.
>> 
>> For that you would need editing file / editing contents action, but
>> this is explicitely excluded in current version of Pavan's proposal :-(
> 
> Is it? I see it only being omitted.

>>> But it needs to be coded so that it does not require an actual checked
>>> out copy (which shouldn't be too much hassle).
>> 
>> It would require using 'git hash-object -t blob -w --stdin' (from body
>> submitted via POST from textarea) plus 'git update-index --cacheinfo'.
> 
> Yes. Not a whole lot of effort, seems to me. A downside is that you
> cannot use the working tree - index dichotomy, but life isn't perfect.

>> There is however complication that you would need to do open2/open3
>> because git-hash-object would require bidirectional communication unless
>> you would use temporary file (command_bidi_pipe in Git.pm, untested).
> 
> I think even just going through a temporary file is fine for initial
> implementation.

> a) File Structure:
> 
>    * gitweb.pl -- Main script parsing urls and calling required modules
>    * gitweb.css -- The style for the gitweb pages.
>    * gitweb.js -- javascript to make gitweb more interactive
>    * git-logo.png
>    * git-favicon.png
>    * Makefile --  Responsible for installing gitweb
>    * lib (dir) -- some basic files like config, view and other actions
>       * config.pm
>       * view.pm
>       * default.pm -- this just outputs the list of all projects.
>       * {actions}.pm -- One file for every action

> The current gitweb makefile makes a gitweb.cgi from the perl script
> and requires a server for it's working. I would like to continue this
> process but the change will be in the gitweb perl script. The new
> script includes config and other basic files, checks the URL, parses
> it, detects the action, uses the output and along with view.pm gives
> out a proper HTML, CSS web page.

> b) Read modules of the client: (most of this need not be written, just
> need to be organised)
> 
>   1. See the status of repository [git status]
>   2. Show diff of the current working file compared to HEAD [git diff]
>   3. List all the commits with pagination [git log]
>   4. With every commit we can
>          * Visualise trees [git ls-tree]
>          * Visualise files and diffs [git show]
>          * Visualise annotations [git blame]
>   5. List all branches including remote ones [git branch]
>   6. Search commits, branches, authors etc.. [git grep]
> 
> c) Write modules of the client:
> 
>   1. Add Existing repositories to the gitweb -- This will list the
> given repo into static list of repos.
>   2. Create new/Clone repositories into a given path [git init | git
> clone] -- This will create new repo and list it
>   3. Add/Remove/Move files [git add | git rm | git mv]
>   4. Stage/Unstage files [git add | git reset]
>   5. Add files to ignore list when u click on 'Ignore' link
>   6. Discard changes to a file in working copy [git reset]
>   7. Commit to the repository with a log message and an optional
> sign-off [git commit]
>   8. Manage branches [git branch]
>   9. A simple branch merging* [git merge]
>  10. Creating tags [git tag]
>  11. Implementing a simple file editor
>  12. Checkout code to a specific commit or branch or tag [git checkout]
>  13. Editing config for remotes [git remote]
>  14. Push to a remote branch [git push]
>  15. Fetch/Pull from a remote branch [git fetch | git pull]
>  16. Garbage collection [git gc | git count-objects | git fsck | git prune]
>  17. Search for a part of code using pickaxe

> d) Usage of the client:
> 
> This client can be used in 2 ways.
> 
> * Install a local version using instaweb - The gitweb will be only
> accessible by you. You can browse through the git repository using
> read modules and simultaneously work on them using write modules.
> * Install on intranet - A company when installs this gitweb along with
> some other login and account managing scripts will be able to order
> their employees to login and ask them to work on the code with out the
> security risk of providing ssh access to the git repository host. The
> authentication support can be implemented as an optional part of my
> proposal.
> * Install on web - Just like normal gitweb, or enable write modules to
> look like gist.github.com

>> d) Usage of the client:
>> 
>> This client can be used in 2 ways.
>> 
>> * Install a local version using instaweb - The gitweb will be only
>> accessible by you. You can browse through the git repository using
>> read modules and simultaneously work on them using write modules.
>> * Install on intranet - A company when installs this gitweb along with
>> some other login and account managing scripts will be able to order
>> their employees to login and ask them to work on the code with out the
>> security risk of providing ssh access to the git repository host. The
>> authentication support can be implemented as an optional part of my
>> proposal.
>> * Install on web - Just like normal gitweb, or enable write modules to
>> look like gist.github.com
>
> Note that for the latter two, operation mode without working copy is
> essential; I have not seen you address it anywhere.

> Petr Baudis <pasky@suse.cz> writes:
> 
> > Note that for the latter two, operation mode without working copy is
> > essential; I have not seen you address it anywhere.
> 
> What do you mean by "without working copy"?  Is the proposal about having
> a working copy _per_ client on the server side, and the file editor and
> goodies listed in the "Wrote modules" list operate on these files?

> Perhaps you meant to say "without working copy on the client side", and if
> that is the case I think we are on the same wavelength.  That is exactly
> why I earlier said that I imagine that the "Gitweb client write support"
> would be based on something more standard like DeltaV, instead of rolling
> a custom hack that is not compatible with anybody else.

>> The lib directory will also contain
>> some basic modules like Gitweb::Repo, Gitweb::Commit which will make
>> developing further functionalities easier.
>
> Beware, this might be an awful can of worms. The previous gitweb SoC
> project failed to get merged in part due to trying to do something like
> this.
>
> I recommend to avoid any large architectural changes and just shuffle
> around all the utility routines to lib/Gitweb.pm or so.

>> d) Usage of the client:
>>
>> This client can be used in 2 ways.
>>
>> * Install a local version using instaweb - The gitweb will be only
>> accessible by you. You can browse through the git repository using
>> read modules and simultaneously work on them using write modules.
>> * Install on intranet - A company when installs this gitweb along with
>> some other login and account managing scripts will be able to order
>> their employees to login and ask them to work on the code with out the
>> security risk of providing ssh access to the git repository host. The
>> authentication support can be implemented as an optional part of my
>> proposal.
>> * Install on web - Just like normal gitweb, or enable write modules to
>> look like gist.github.com
>
> Note that for the latter two, operation mode without working copy is
> essential; I have not seen you address it anywhere.

> 1.What is the goal of your project?
> The project goal is to try and implement write functionalities into gitweb
> to go along with it's browsing functionalities. Another goal is to split
> gitweb Perl script and reorganize its structure. I would like to split the
> gitweb script in such a way that, in the future others will be able to
> develop more functionalities for gitweb (let it be 'read' or 'write'
> actions) with the help of the framework like structure of the new gitweb.
> 
> 'read' means browsing through the code and repository
> 'write' means working on the code and repository.
> 
> I will be describing about them detailedly in the later parts of the
> proposal.

> 2.How would you measure its success or failure?
> There are two parameters which would majorly determine the success or
> failure of the project.
> 
>    * Splitting gitweb such that there should be no problem with the
> installation of gitweb across cross servers and cross systems.
>    * Working with new addition to gitweb should be as easy as working with
> other git GUIs (git commit tools)
>    * User friendly graphical interface with smart UI design
> 
> 3.Describe your project in more detail.
> I would like to split the currently 6800 long piece of code in
> gitweb.plperl script into small files which will result in better
> readability,
> maintainability and modifiability. The file structure of the new gitweb is
> given below and I will explain the working after it.
> 
> (From now on, I would like to call the actions of gitweb as modules of
> gitweb)

> On Wednesday 21 April 2010 22:49:02 Pavan Kumar Sunkara wrote:
>> 1.What is the goal of your project?
>> The project goal is to try and implement write functionalities into gitweb
>> to go along with it's browsing functionalities. Another goal is to split
>> gitweb Perl script and reorganize its structure. I would like to split the
>> gitweb script in such a way that, in the future others will be able to
>> develop more functionalities for gitweb (let it be 'read' or 'write'
>> actions) with the help of the framework like structure of the new gitweb.
>>
>> 'read' means browsing through the code and repository
>> 'write' means working on the code and repository.
>>
>> I will be describing about them detailedly in the later parts of the
>> proposal.
>
> Perhaps this sentence could be worded like this:
>
> "I will describe in detail the read and write actions in the later part of the
> proposal."
>
>> 2.How would you measure its success or failure?
>> There are two parameters which would majorly determine the success or
>> failure of the project.
>>
>>    * Splitting gitweb such that there should be no problem with the
>> installation of gitweb across cross servers and cross systems.
>>    * Working with new addition to gitweb should be as easy as working with
>> other git GUIs (git commit tools)
>>    * User friendly graphical interface with smart UI design
>>
>> 3.Describe your project in more detail.
>> I would like to split the currently 6800 long piece of code in
>> gitweb.plperl script into small files which will result in better
>> readability,
>> maintainability and modifiability. The file structure of the new gitweb is
>> given below and I will explain the working after it.
>>
>> (From now on, I would like to call the actions of gitweb as modules of
>> gitweb)
>
> Perhaps it would be better to state that in the end each action will have its
> own Perl module.

> Though I agree with Petr that first you should probably just shuffle around all
> the utility routines in one module and develop write actions in another module
> that uses the first one.
>
> Thanks,
> Christian.
>
>

>
> On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:
>
> > Here is my rewritten proposal as Christian and Petr asked me to write.
> > Please go through this.
>
> Thanks for sending this to git mailing list for review.
>
> > =====================================================
> >
> > Splitting gitweb and developing write functionalites
> > Student:        Pavan Kumar Sunkara
> >
> > This project aims at splitting and organising the 6800 lines code of
> > gitweb.pl into a nicely structured set of files. Not only providing
> > the browsing functionalities in gitweb, but it also aims at developing
> > functionalities for working on a git repository.
>
> First, a question: do you feel proficient enough in Perl (and in web
> scripting in Perl), or do you prefer other programming language for
> web, like e.g. Python?  If you feel like you would do better programming
> in Python (or PHP, or Ruby) rather than in Perl, you could write the
> main part of this GSoC project in said language, and provide only hooks
> into gitweb (with the help of developers on git mailing list).
>

>
> Second, it would probably be not "splitting ... into ... a set of
> files", but rather "splitting gitweb into modules" (see e.g.
> Web::Simple, SVN::Web, etc).
>

>
> I don't understand "providing the browsing functionalities in gitweb":
> gitweb *has* browsing functionalities.  The whole idea of integrating
> your "Web CLient" with gitweb was to avoid duplicating repository
> browsing and vieweing functionality, and to concentrate on the "edit"
> part.
>

>
> "It aims at developing functionalities for working on a git repository."
> Not only this is not grammatical, but also doesn't tell us the goal
> of your project.  Is it something to edit files and create commits via
> web, be to git-gui what git-instaweb is to gitk?  Is it about editing
> gitweb-specific configuration, like README/README.html and 'description'
> file from web browser?  Is it managing git repositories, i.e. create,
> fork or clone and mirror repositories, something that Gerrit does for
> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?
>

>
> >
> > First I will describe my project goals, giving an overview of what I
> > would like to contribute to git. Second I will give the proposed time
> > line of the project which includes all the information about the
> > project. Lastly I will give some information about myself.
>
> This paragraph is in my opinion a bit unnecessary.  It would be useful
> if it was 50+ pages book, or even 10+ pages article.

>
> >
> > Project Goals
> >
> > 1. What is the goal of your project?
> >
> > The project goal is to try and implement write functionalities into
>
> What are those "write functionalities"?  There are many different
> features that can be described as "write functionalities": what exactly
> do you want to do?  This description is a bit too generic.
>
> > gitweb along with it's browsing functionalities.
>
> You probably meant here "into gitweb to go along with its browsing
> capabilities".

>
> > It also aims at splitting and organising the structure of gitweb
> > perl script.
>
> Grammar.  "Another goal is to split gitweb Perl script and reorganize
> its structure".
>

>
> >
> > I would like to split the gitweb script in such a way that, in the
> > future others will be able to develop more functionalities for gitweb
> > (let it be 'read' or 'write' actions) with the help of the framework
> > like structure of the new gitweb.
>
> O.K.
>
> One of the goals for splitting gitweb is, I think, making it easier to
> manage gitweb codebase, i.e  making it easier to contribute to gitweb,
> and to add extra features to it.
>

>
> >
> > * 'read' means browsing through the code and repository
> > * 'write' means working on the code and repository.
>
> This doesn't tell us much.
>
> >
> > 2.How would you measure its success or failure?
> >
> > There are two parameters which would majorly determine the success or
> > failure of the project.
> >
> >    * Splitting gitweb such that there should be no problem with the
> > installation of gitweb across cross servers and cross systems.
>
> That is a good idea: the requirement that installing gitweb should
> be easy after splitting it, and it should work for many different
> web servers, and across different systems.  Perhaps it would be good
> idea to add that we want to be able to install gitweb as non root.
>
> >    * It should be possible that the new gitweb requires less time to
> > work on a git repository than any other git client.
>
> I don't understand this sentence.  Could you rephrase this goal?
> Did you wanted to say here that working with new addition to gitweb
> would be as easy as working with other git GUIs (git commit tools)?

>
> >    * User friendly graphical interface with smart UI design when
> > compared to any other git clients or browsers.
>
> This is rather vague for a goal.  Do you want to be able to edit
> files and commit them?  To add new files and remove tracked files
> (or just untrack them)?  To cherry-pick, revert, amend commit?
> To switch between branches and reqwind a branch?  To run and visualize
> git-bisect?  To merge branches and resolve merge conflicts?  To rebase
> and resolve rebase conflicts?

>
> >
> > 3.Describe your project in more detail.
> >
> > I would like to split the currently 6800 long piece of code in
> > gitweb.pl perl script into small files which will result in better
> > readability, maintainability and modifiability. The file structure of
> > the new gitweb is given below and I will explain the working after it.
>
> O.K. this describes the new goal: splitting gitweb to make it easier to
> add new features, like the example "write" feature.
>
> >
> > (From now on, I would like to call the actions of gitweb as modules of
> gitweb)
> >
> > a) File Structure:
> >
> >    * gitweb.pl -- Main script parsing urls and calling required
> >      modules
>
> O.K.  This would be the main application: the one responsible for
> dispatch (and perhaps parsing command line options, like git-instaweb).
>
> >    * gitweb.tpl -- The template of the web page (GUI) in which
> >      modules are embedded
>
> Errrr... what?  Gitweb currently does not use templating engine.
> There are no templating engines in Perl core, writing yet another one
> only for gitweb would be stupid, and choosing one would I guess result
> in bikeshedding spanning whole summer and then some (which one to
> choose: Template Toolkit with its domain specific language,  Haml-like
> perlish templates of Template::Declare and Markapl, or pure (X)HTML
> templates of Template::Semantic and HTML::Zoom?).
>
> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC
> model, containing subroutines responsible for the look of gitweb?
>

>
> >    * gitweb.css -- The style for the gitweb pages.
> >    * gitweb.js -- javascript to make gitweb more interactive
>
> You forgot other static files: git-logo.png and git-favicon.png.
>
> You also forgot the build system: Makefile, or Makefile.PL (if gitweb
> is to use ExtUtils::MakeMaker like Git.pm does), or Build.PL (if
> gitweb is to use Module::Build instead).  The very important part.

>
> >    * modules (dir) -- directory containing the write and read modules.
> >    * lib (dir) -- some basic files like config, error_handler,
> > templater, redirecter, htmlHelper etc..
>
> I'm not sure about modules/ directory: wouldn't lib/ be enough?
> What needs to be in modules/ that cannot be put in lib/?
>
> Also you wouldn't want to split gitweb into files each containing single
> subroutine, but in packages such like Gitweb::Utils, Gitweb::Repo,
> Gitweb::Action::ProjectsList (this is only a proposal).
>

>
> >
> > The current gitweb makefile makes a gitweb.cgi from the perl script
> > and requires apache or lighttpd server for it's working.
>
> Errr... gitweb Makefile does not require Apache or lighttpd server
> (that is what you sentence seems to imply).
>
> What is more, gitweb requires to run any web server that supports CGI
> (including but *not limited to* Apache, lighttpd, nginx,...) or Apache
> with mod_perl (via ModPerl::Registry handler).  It s not limited to
> Apache or lighttpd.

>
> > I would like
> > to continue this process but the change will be in the gitweb perl
> > script.
>
> I don't quite understand this sentence.  What would be the build
> procedure for new gitweb + "Web Client", and how such new gitweb (with
> or without "Web Client" can be installed, optionally how such new
> gitweb with "Web Client" can be run (like git-instaweb.sh)?
>

>
> > The new script includes config and other basic files, checks
> > the URL, parses it, detects the module, manage session and includes
> > the proper module.
>
> O.K., so after splitting the main gitweb.perl file (from which
> gitweb.cgi would be created during build) includes configuration
> (hmmm... shouldn't default configuration and perhaps reading
> site-specific configuration too be put into separate Perl module?),
> dispatch (checking and parsing URL, verifying parameters, and
> choosing action to run), and checking which extra modules (and
> therefore which actions) are available.
>
> "Manage session"... err, current gitweb does not need session
> management.  Would the "write" module require it, even if we can assume
> that you are the only client like with git-instaweb, and authentication
> is not required?  I would also recommend to not reinwent the wheel,
> and if you feel that "write" module really needs session management,
> use some existing CPAN module for it like e.g. CGI::Session, or at least
> borrow (some) code from it.
>

>
> > It then retreives the output of the module and
> > substitutes it with the gitweb.tpl template file string and gives out
> > a proper HTML, CSS web page.
>
> As I said gitweb currently do not use templating engine.  Currently
> subroutines that render gitweb actions use git_header_html and
> git_footer_html and similar subroutines... if needed.
>
> Sidenote: I'd prefer that gitweb do not loose ability to stream its
> response, at least for some actions like 'blob_plain', 'patches', and
> what's most important for performance reasons 'snapshot' view.
>

>
> > It also contains some basic library files
> > in the lib directory.
>
> The new split gitweb, or the new gitweb.perl script?  It is not clear
> what "it" refers to here.  What does "some basic library files" means?
> If you want for functional groups of subroutines from gitweb to be split
> into separate files/modules, like Gitweb::Utils with href() etc, like
> Gitweb::Repo with parse_commit and similar, please say it explicitely.
>

>
> > The new gitweb uses session variables to track
> > some of the variables rather than including them in the url.
>
> Why?  If it is possible and feasible to be sessionless, then it is
> better to do so.  Session state consumes resources on the server.
> HTTP protocol is naturally stateless.
>
> > The write
> > modules need not be working in a gitweb installation like repo.or.cz,
> > so we will also have an option to disable the write modules.
>
> That is a good idea: if "write" module is not installed, its features
> are not available.
>

>
> >
> > b) Write modules of the client:
> >
> >   1. Add existing repositories to the gitweb -- This will list the
> >      given repo into gitweb config
>
> Note that if gitweb scans for repositories ($projects_list is
> a directory, not a file with the list of projects), gitweb would detect
> new repository automatically.  This feature (autodetecting
> repositories) is fore example requirement on git.kernel.org.
>

>
> >   2. Create new/Clone repositories into a given path [git init |
> >     git clone] -- This will create new repo and list it
>
> "Create new repository" and "fork it", like Girocco does for
> repo.or.cz...

>
> >   3. Add/Remove/Move files [git add | git rm | git mv]
> >   4. Stage/Unstage files [git add | git reset]
> >   5. Add files to ignore list when you click on 'Ignore' link
>
> All the above require ability to display a state of a working directory,
> i.e. something like 'tree' view but for working area of repository (or
> the index) rather than taken from some commit.
>

>
> >   6. Discard changes to a file in working copy [git reset]
>
> O.K.
>
> >   7. Commit to the repository with a log message and an optional
> >      sign-off [git commit]
>
> You would probably want also to display status of the files in the
> working directory (this goes along with 'tree' view for files in
> working area: we would probably want to display state for those files),
> and to display diff between current HEAD and working area.  Gitweb can
> display commitdiff for a given commit, and (what is less known) diff
> between two arbitrary commits only.

>
> >   9. A simple branch merging* [git merge]
>
> Do you mean here by "simple" merge that does not lead to merge
> conflicts?

>
> >  11. Checkout code to a specific commit or branch or tag
> >      [git checkout]
>
> Note that "git checkout <branch>" is switching branches.

>
> >  12. Push to a remote branch [git push]
> >  13. Fetch/Pull from a remote branch [git fetch | git pull]
>
> Yo would need support for either editing config, or for interface to
> [git remote add] first, otherwise the only remote available would be
> 'origin'.  Unless you are interested in pushing to / fetching from
> repository given by URL...
>

>
> >  14. Garbage collection [git gc]
>
> You would probably want to be able to gather statistics, a la
> [git count-objects -v].

>
> >  15. Search for a part of code [git grep]
>
> Note that current gitweb includes some support for 'grep' search,
> but obviously you can only search repository (some specified commit),
> not index nor working area.
>

>
> >
> > * - Merging two branches can be quite complicated
> >
> > c) Read modules of the client: (most of this need not be written, just
> > need to be organised)
> >
> >   1. See the status of repository [git status]
>
> New, needed for commit.
>
> >   2. Show diff of the current working file compared to HEAD [git diff]
>
> New, needed for commit.
>
> >   3. List all the commits with pagination [git log]
>
> Exists in gitweb.
>
> >   4. With every commit we can
> >          * Visualise trees [git ls-tree]
> >          * Visualise files and diffs [git show]
> >          * Visualise annotations [git blame]
>
> All those exists already in gitweb.

>
> >   5. List all branches including remote ones [git branch]
>
> Remote tracking branches are not currently supported, but gitweb can
> display local branches and tags.
>
> >   6. Search commits, branches, authors etc..
>
> Exists in gitweb.
>
> >
> > d) Usage of the client:
> >
> > This client can be used in 2 ways.
> >
> > * Install a local version using instaweb - The gitweb will be only
> > accessible by you. You can browse through the git repository using
> > read modules and simultaneously work on them using write modules.
>
> This part could be doeable dusing GSoC 2010 (if this project gets
> accepted), I think.

>
> > * Install on intranet - A company when installs this gitweb along with
> > some other login and account managing scripts will be able to order
> > their employees to login and ask them to work on the code with out the
> > security risk of providing ssh access to the git repository host.
> > * Install on web - Just like normal gitweb, or enable write modules to
> > look like gist.github.com
>
> This would require authentication support, which I think might be too
> much for GSoC.

>
> > e) Future functionalities:
> >
> >    * Implementing a file editor
>
> O.K., although without at least being able to edit file in textarea,
> or to upload new version of a file you would need something outside
> "write" module to create new commits anyway.
>
> >    * Rebasing branches
> >    * Content History browser - (The gsoc 2010 idea in wiki)
> >    * Implementing git bisect
> >    * Cherry picking
> >    * Patches management along with email
>
> O.K.
>
> >    * Viewing git stats in an interactive user interface
>
> O.K.
>
> >    * Developing API to work with gitweb for storing information in
> > form of a git repository
>
> What you mean by that?
>

>
> [...]
> > f) Sample Work - Mockup:
> >
> > A small pre-version smaple of the project can seen in my github
> > repository named 'gittor' here. It is written in python and just a
> > small sampe of my work in write modules. This client is capable of
> > building any other functionality and can integrate the functionalities
> > of any other git tools.
>
> That is very good... but see the question at the beginning of my email.

>
> > TimeLine
>
> [...]
> > [June 3rd week]
> > Complete module from W1 to W3
>
> Don't forget to write automated tests, if it is possible.
>
> Also, W1 to W3 do not tell me much here.
>
> > 3. Academic Experience
> >
> > I beleive I am a fast learner and have learnt most of the famous
> > programming languages in the coding world. Some of the courses which
> > are relevant to my GSoC project and proposal are:
> >
> >    * Data Structures and Algortihms
> >    * Advanced Computer Programming
> >    * Introduction to Computer Programming
> >
> > The other courses which I have taken and non-relevant to the project
> > are Languages Machines and Computations, Switching Circuits and Logic
> > Design, Computer Architecture and Organisation.
> >
> > Different Programming languages which I am comfortable with:
> >
> >    * Python
> >    * PHP
> >    * SQL
> >    * Javascript
> >    * AJAX
> >    * C
> >    * C++
> >    * HTML
> >    * CSS
> >    * Java
> >    * Verilog
> >    * Assembly language
>
> Unfortunately Perl (the language gitweb is written in) is missing...
> See also first question in this email of mind.
>
> AJAX is not programming language: it is technique.  (Also neither
> HTML nor CSS are *programming* languages in strict sense, but that
> is just nitpicking...).

>
> [...]
> > 4. Involvement with Git
> >
> > I use git for most of my projects and am fascinated by it's speed and
> > uasbility. I think it is and is going to be the best content tracker
> > ever known to the world.
> >
> > I have been subscribed to git mailing list for 2 months and have
> > already put one of my ideas forward to the git developers in the
> > thread linked here
> >
> > I also submitted a patch which advices the users in git status to add
> > a file to gitignore if he want to ignore it permanently. It can seen
> > in this mailing list thread here.
>
> Good.
>
> --
> Jakub Narebski
> Poland

>>> =====================================================
>>>
>>> Splitting gitweb and developing write functionalites
>>> Student:        Pavan Kumar Sunkara
>>>
>>> This project aims at splitting and organising the 6800 lines code of
>>> gitweb.pl into a nicely structured set of files. Not only providing
>>> the browsing functionalities in gitweb, but it also aims at developing
>>> functionalities for working on a git repository.
>>
>> First, a question: do you feel proficient enough in Perl (and in web
>> scripting in Perl), or do you prefer other programming language for
>> web, like e.g. Python?  If you feel like you would do better programming
>> in Python (or PHP, or Ruby) rather than in Perl, you could write the
>> main part of this GSoC project in said language, and provide only hooks
>> into gitweb (with the help of developers on git mailing list).
>
> I don't know perl but learning it and becoming proficient in it won't be a
> matter for me. I believe I am a fast learner and I am a computer science
> student in the top university of India. I learnt python in an hour and
> became proficient in it by a week. So learning perl won't be a matter for
> me.

>> Second, it would probably be not "splitting ... into ... a set of
>> files", but rather "splitting gitweb into modules" (see e.g.
>> Web::Simple, SVN::Web, etc).
>>
> I would like to take the majority opinion on how to split gitweb.

>> "It aims at developing functionalities for working on a git repository."
>> Not only this is not grammatical, but also doesn't tell us the goal
>> of your project.  Is it something to edit files and create commits via
>> web, be to git-gui what git-instaweb is to gitk?  Is it about editing
>> gitweb-specific configuration, like README/README.html and 'description'
>> file from web browser?  Is it managing git repositories, i.e. create,
>> fork or clone and mirror repositories, something that Gerrit does for
>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?
>>
> I think you understood it from the later part of my proposal.

>>>    * User friendly graphical interface with smart UI design when
>>> compared to any other git clients or browsers.
>>
>> This is rather vague for a goal.  Do you want to be able to edit
>> files and commit them?  To add new files and remove tracked files
>> (or just untrack them)?  To cherry-pick, revert, amend commit?
>> To switch between branches and reqwind a branch?  To run and visualize
>> git-bisect?  To merge branches and resolve merge conflicts?  To rebase
>> and resolve rebase conflicts?
> 
> Yes, exactly. I think you haven't read the whole proposal before writing
> this. :-)

>>>    * gitweb.tpl -- The template of the web page (GUI) in which
>>>      modules are embedded
>>
>> Errrr... what?  Gitweb currently does not use templating engine.
>> There are no templating engines in Perl core, writing yet another one
>> only for gitweb would be stupid, and choosing one would I guess result
>> in bikeshedding spanning whole summer and then some (which one to
>> choose: Template Toolkit with its domain specific language,  Haml-like
>> perlish templates of Template::Declare and Markapl, or pure (X)HTML
>> templates of Template::Semantic and HTML::Zoom?).
>>
>> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC
>> model, containing subroutines responsible for the look of gitweb?
>>
> I would like to add a small 50 lines code for templater class which does
> string substitution and embed the module output into tpl file. This method
> reduces the subroutines like git_header_html etc.. A small example of
> templater class can be found at http://matetelki.com/blog/?p=71. It isn't
> exactly the same i use but you get the basic idea. right ?

>>>    * modules (dir) -- directory containing the write and read modules.
>>>    * lib (dir) -- some basic files like config, error_handler,
>>> templater, redirecter, htmlHelper etc..
>>
>> I'm not sure about modules/ directory: wouldn't lib/ be enough?
>> What needs to be in modules/ that cannot be put in lib/?

>>> The new script includes config and other basic files, checks
>>> the URL, parses it, detects the module, manage session and includes
>>> the proper module.
>>
>> O.K., so after splitting the main gitweb.perl file (from which
>> gitweb.cgi would be created during build) includes configuration
>> (hmmm... shouldn't default configuration and perhaps reading
>> site-specific configuration too be put into separate Perl module?),
>> dispatch (checking and parsing URL, verifying parameters, and
>> choosing action to run), and checking which extra modules (and
>> therefore which actions) are available.
>>
>> "Manage session"... err, current gitweb does not need session
>> management.  Would the "write" module require it, even if we can assume
>> that you are the only client like with git-instaweb, and authentication
>> is not required?  I would also recommend to not reinwent the wheel,
>> and if you feel that "write" module really needs session management,
>> use some existing CPAN module for it like e.g. CGI::Session, or at least
>> borrow (some) code from it.
>>
> I mean wouldn't using session be good thing to add. It doesn't need to use
> parameters like project name all the time in the URL.

>>> b) Write modules of the client:
>>>
>>>   1. Add existing repositories to the gitweb -- This will list the
>>>      given repo into gitweb config
>>
>> Note that if gitweb scans for repositories ($projects_list is
>> a directory, not a file with the list of projects), gitweb would detect
>> new repository automatically.  This feature (autodetecting
>> repositories) is fore example requirement on git.kernel.org.
>>
> Let us say if there are multiple repositories in multiple paths, wouldn't it
> be good to add a single project. This option will be available along with
> scanning $projects_root.

>>>  12. Push to a remote branch [git push]
>>>  13. Fetch/Pull from a remote branch [git fetch | git pull]
>>
>> You would need support for either editing config, or for interface to
>> [git remote add] first, otherwise the only remote available would be
>> 'origin'.  Unless you are interested in pushing to / fetching from
>> repository given by URL...
>>
> I think i missed that point. all functionalites with "git remote" will be
> added too.

>>> d) Usage of the client:
>>>
>>> This client can be used in 2 ways.
>>>
>>> * Install a local version using instaweb - The gitweb will be only
>>> accessible by you. You can browse through the git repository using
>>> read modules and simultaneously work on them using write modules.
>>
>> This part could be doable during GSoC 2010 (if this project gets
>> accepted), I think.
> 
> Yes. This is the main thing that is needed for a average git user.

>>> * Install on intranet - A company when installs this gitweb along with
>>> some other login and account managing scripts will be able to order
>>> their employees to login and ask them to work on the code with out the
>>> security risk of providing ssh access to the git repository host.
>>> * Install on web - Just like normal gitweb, or enable write modules to
>>> look like gist.github.com
>>
>> This would require authentication support, which I think might be too
>> much for GSoC.
> 
> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I
> hope to provide an authentication wrapper for gitweb in future.

>>>    * Developing API to work with gitweb for storing information in
>>> form of a git repository
>>
>> What you mean by that?
>>
> I mean, I will be providing an web API wrapper for gitweb which can be used
> by other web developers to store any information they get into a git
> repository form and can use it to see the changes they made to the
> information step  by step.

> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:
>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Sun, 18 April 2010, Pavan Kumar Sunkara wrote:
>
>>>> =====================================================
>>>>
>>>> Splitting gitweb and developing write functionalites
>>>> Student:        Pavan Kumar Sunkara
>>>>
>>>> This project aims at splitting and organising the 6800 lines code of
>>>> gitweb.pl into a nicely structured set of files. Not only providing
>>>> the browsing functionalities in gitweb, but it also aims at developing
>>>> functionalities for working on a git repository.
>>>
>>> First, a question: do you feel proficient enough in Perl (and in web
>>> scripting in Perl), or do you prefer other programming language for
>>> web, like e.g. Python?  If you feel like you would do better programming
>>> in Python (or PHP, or Ruby) rather than in Perl, you could write the
>>> main part of this GSoC project in said language, and provide only hooks
>>> into gitweb (with the help of developers on git mailing list).
>>
>> I don't know perl but learning it and becoming proficient in it won't be a
>> matter for me. I believe I am a fast learner and I am a computer science
>> student in the top university of India. I learnt python in an hour and
>> became proficient in it by a week. So learning perl won't be a matter for
>> me.
>
> I can agree that you would be able to learn Perl in a week.  I do not
> think however that you can become proficient in Perl (and neither in any
> other non-trivial programming language) in such short time.  The question
> remains if you can be proficient enough for the task in question...

>>> Second, it would probably be not "splitting ... into ... a set of
>>> files", but rather "splitting gitweb into modules" (see e.g.
>>> Web::Simple, SVN::Web, etc).
>>>
>> I would like to take the majority opinion on how to split gitweb.
>
> Errr... my comment was about technical language / jargon used...
>
> As to "I would like to take the majority opinion on how to split gitweb":
> in my opinion you would need to have your own idea on how to split gitweb
> yourself, to avoid possibility of wasting time on bikeshedding[1].
> Of course this would be based on discussion here on git mailing list.
> All of this assuming that this project would get accepted.
>
> [1] http://en.wikipedia.org/wiki/Bikeshed

>>> "It aims at developing functionalities for working on a git repository."
>>> Not only this is not grammatical, but also doesn't tell us the goal
>>> of your project.  Is it something to edit files and create commits via
>>> web, be to git-gui what git-instaweb is to gitk?  Is it about editing
>>> gitweb-specific configuration, like README/README.html and 'description'
>>> file from web browser?  Is it managing git repositories, i.e. create,
>>> fork or clone and mirror repositories, something that Gerrit does for
>>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?
>>>
>> I think you understood it from the later part of my proposal.
>
> Yes, I found it in later parts of proposal, but don't you think that
> this goal of this project should be stated upfront, so that one can
> know what this project is to be about from project description itself?

>>>>    * User friendly graphical interface with smart UI design when
>>>> compared to any other git clients or browsers.
>>>
>>> This is rather vague for a goal.  Do you want to be able to edit
>>> files and commit them?  To add new files and remove tracked files
>>> (or just untrack them)?  To cherry-pick, revert, amend commit?
>>> To switch between branches and reqwind a branch?  To run and visualize
>>> git-bisect?  To merge branches and resolve merge conflicts?  To rebase
>>> and resolve rebase conflicts?
>>
>> Yes, exactly. I think you haven't read the whole proposal before writing
>> this. :-)
>
> I have not.  I got it from discussion in parallel subthread, so I asked
> for clarification.  But I should have to read the whole proposal, or
> know extra information to get what you were trying to say here.
> Be specific (but not too detailed), not vague in describing goals.

>>>>    * gitweb.tpl -- The template of the web page (GUI) in which
>>>>      modules are embedded
>>>
>>> Errrr... what?  Gitweb currently does not use templating engine.
>>> There are no templating engines in Perl core, writing yet another one
>>> only for gitweb would be stupid, and choosing one would I guess result
>>> in bikeshedding spanning whole summer and then some (which one to
>>> choose: Template Toolkit with its domain specific language,  Haml-like
>>> perlish templates of Template::Declare and Markapl, or pure (X)HTML
>>> templates of Template::Semantic and HTML::Zoom?).
>>>
>>> Or did you mean lib/Gitweb/View/Default.pm - the view part of MVC
>>> model, containing subroutines responsible for the look of gitweb?
>>>
>> I would like to add a small 50 lines code for templater class which does
>> string substitution and embed the module output into tpl file. This method
>> reduces the subroutines like git_header_html etc.. A small example of
>> templater class can be found at http://matetelki.com/blog/?p=71. It isn't
>> exactly the same i use but you get the basic idea. right ?
>
> Currently gitweb does not use any templating engine.  Adding it would
> be additional work, in my opinion not really necesary for the goals of
> project (splitting gitweb is more on less needed to be able to add
> large new feature, such as committool / "write" bit).  I don't think
> there is enough time to (optionally) code and add templating to gitweb.
>
> Additionally, while adding very simple templating class wouldn't be
> to much violation of programming guidelines (and for example both
> Mojolicius and Dancer web micro-frameworks include their own simple
> templating system), I am afraid that simple string / variable
> substitution would be not enough for gitweb: loops and conditionals
> would also be required.  Also we would probably want for templating
> system to automatically escape (when requested).  So templating engine
> grows... and then it would really be better to just use one of existing
> templating modules from CPAN (http://search.cpan.org), or add adapter
> to one of templating system from CPAN (like Catalyst web framework
> does it).
>
> Also if you are not proficient in Perl, I would be aftraid that your
> homebrew templating engine would affect gitweb performance...
>
>
> In short: no time to add templating support to gitweb.

>
>>>>    * modules (dir) -- directory containing the write and read modules.
>>>>    * lib (dir) -- some basic files like config, error_handler,
>>>> templater, redirecter, htmlHelper etc..
>>>
>>> I'm not sure about modules/ directory: wouldn't lib/ be enough?
>>> What needs to be in modules/ that cannot be put in lib/?
>
> I guess (please correct me if I am wrong) that lib/ would contain modules
> *required* by gitweb, and modules/ would contain *optional* modules
> needed for extra functionality (for extra features).

>>>> The new script includes config and other basic files, checks
>>>> the URL, parses it, detects the module, manage session and includes
>>>> the proper module.
>>>
>>> O.K., so after splitting the main gitweb.perl file (from which
>>> gitweb.cgi would be created during build) includes configuration
>>> (hmmm... shouldn't default configuration and perhaps reading
>>> site-specific configuration too be put into separate Perl module?),
>>> dispatch (checking and parsing URL, verifying parameters, and
>>> choosing action to run), and checking which extra modules (and
>>> therefore which actions) are available.
>>>
>>> "Manage session"... err, current gitweb does not need session
>>> management.  Would the "write" module require it, even if we can assume
>>> that you are the only client like with git-instaweb, and authentication
>>> is not required?  I would also recommend to not reinwent the wheel,
>>> and if you feel that "write" module really needs session management,
>>> use some existing CPAN module for it like e.g. CGI::Session, or at least
>>> borrow (some) code from it.
>>>
>> I mean wouldn't using session be good thing to add. It doesn't need to use
>> parameters like project name all the time in the URL.
>
> Using sessions is not without cost: you would (usually) need to store
> extra information on the server.
>
> Also one usually wants for URLs to be bookmarkeable.  One would want
> to be able to send link to be copy'n'pasted.
>
> If sessions are to make gitweb URLs shorter: forget it.  First, it would
> be not necessary for your project.  Second, this is not the way to have
> shorter URLs.
>
> See also the whole idea of stateless REST interface.

>>>> b) Write modules of the client:
>>>>
>>>>   1. Add existing repositories to the gitweb -- This will list the
>>>>      given repo into gitweb config
>>>
>>> Note that if gitweb scans for repositories ($projects_list is
>>> a directory, not a file with the list of projects), gitweb would detect
>>> new repository automatically.  This feature (autodetecting
>>> repositories) is fore example requirement on git.kernel.org.
>>>
>> Let us say if there are multiple repositories in multiple paths, wouldn't it
>> be good to add a single project. This option will be available along with
>> scanning $projects_root.
>
> If gitweb is configured to scan for repositories, adding existing git
> repository to gitweb doesn't make sense.  If gitweb is configured to
> use static file with list of repositories, of course it would make
> sense... but then the question is how would one specify location of
> a new repository to add.

>
>>>>  12. Push to a remote branch [git push]
>>>>  13. Fetch/Pull from a remote branch [git fetch | git pull]
>>>
>>> You would need support for either editing config, or for interface to
>>> [git remote add] first, otherwise the only remote available would be
>>> 'origin'.  Unless you are interested in pushing to / fetching from
>>> repository given by URL...
>>>
>> I think i missed that point. all functionalites with "git remote" will be
>> added too.
>
> Good.
>
>>>> d) Usage of the client:
>>>>
>>>> This client can be used in 2 ways.
>>>>
>>>> * Install a local version using instaweb - The gitweb will be only
>>>> accessible by you. You can browse through the git repository using
>>>> read modules and simultaneously work on them using write modules.
>>>
>>> This part could be doable during GSoC 2010 (if this project gets
>>> accepted), I think.
>>
>> Yes. This is the main thing that is needed for a average git user.
>
> The main simplification is that we do not need authentication here,
> only perhaps requirement that server is 'localhost'.

>>>> * Install on intranet - A company when installs this gitweb along with
>>>> some other login and account managing scripts will be able to order
>>>> their employees to login and ask them to work on the code with out the
>>>> security risk of providing ssh access to the git repository host.
>>>> * Install on web - Just like normal gitweb, or enable write modules to
>>>> look like gist.github.com
>>>
>>> This would require authentication support, which I think might be too
>>> much for GSoC.
>>
>> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I
>> hope to provide an authentication wrapper for gitweb in future.
>
> Well, unless there would be time for it after you finish all other work,
> but it is a bit unlikely.

>>>>    * Developing API to work with gitweb for storing information in
>>>> form of a git repository
>>>
>>> What you mean by that?
>>>
>> I mean, I will be providing an web API wrapper for gitweb which can be used
>> by other web developers to store any information they get into a git
>> repository form and can use it to see the changes they made to the
>> information step  by step.
>
> It doesn't tell me much either.  Do you mean some kind of REST API here,
> to be used from other clients, or something like that?

>>>> First, a question: do you feel proficient enough in Perl (and in web
>>>> scripting in Perl), or do you prefer other programming language for
>>>> web, like e.g. Python?  If you feel like you would do better programming
>>>> in Python (or PHP, or Ruby) rather than in Perl, you could write the
>>>> main part of this GSoC project in said language, and provide only hooks
>>>> into gitweb (with the help of developers on git mailing list).
>>>
>>> I don't know perl but learning it and becoming proficient in it won't be a
>>> matter for me. I believe I am a fast learner and I am a computer science
>>> student in the top university of India. I learnt python in an hour and
>>> became proficient in it by a week. So learning perl won't be a matter for
>>> me.
>>
>> I can agree that you would be able to learn Perl in a week.  I do not
>> think however that you can become proficient in Perl (and neither in any
>> other non-trivial programming language) in such short time.  The question
>> remains if you can be proficient enough for the task in question...
> 
> I can learn perl in 3 hours. Becoming proficient in perl is just
> knowing about all the majorly used inbuilt functions and libraries.
> Coming to the concepts of programming, I already know a lot about it
> along with data structures and algortihms. So you need not doubt me on
> this.

>>>> "It aims at developing functionalities for working on a git repository."
>>>> Not only this is not grammatical, but also doesn't tell us the goal
>>>> of your project.  Is it something to edit files and create commits via
>>>> web, be to git-gui what git-instaweb is to gitk?  Is it about editing
>>>> gitweb-specific configuration, like README/README.html and 'description'
>>>> file from web browser?  Is it managing git repositories, i.e. create,
>>>> fork or clone and mirror repositories, something that Gerrit does for
>>>> repo.or.cz (repo.or.cz uses gitweb for viewing repositories)?
>>>>
>>> I think you understood it from the later part of my proposal.
>>
>> Yes, I found it in later parts of proposal, but don't you think that
>> this goal of this project should be stated upfront, so that one can
>> know what this project is to be about from project description itself?
> 
> I thought it should be described later in the "Describe your project
> in more detail" section.  So, I didn't go into details here.

>>>>>    * modules (dir) -- directory containing the write and read modules.
>>>>>    * lib (dir) -- some basic files like config, error_handler,
>>>>> templater, redirecter, htmlHelper etc..
>>>>
>>>> I'm not sure about modules/ directory: wouldn't lib/ be enough?
>>>> What needs to be in modules/ that cannot be put in lib/?
>>
>> I guess (please correct me if I am wrong) that lib/ would contain modules
>> *required* by gitweb, and modules/ would contain *optional* modules
>> needed for extra functionality (for extra features).
> 
> You are half correct.
> lib/ contains modules *required* by gitweb
> modules/ contains actions *performed* in gitweb like commitlog,
> snapshot etc.. (write actions too)
> 
> Maybe I will rename it to actions/ to not to be confused.

>>>>>   1. Add existing repositories to the gitweb -- This will list the
>>>>>      given repo into gitweb config
>>>>
>>>> Note that if gitweb scans for repositories ($projects_list is
>>>> a directory, not a file with the list of projects), gitweb would detect
>>>> new repository automatically.  This feature (autodetecting
>>>> repositories) is fore example requirement on git.kernel.org.
>>>>
>>> Let us say if there are multiple repositories in multiple paths, wouldn't it
>>> be good to add a single project. This option will be available along with
>>> scanning $projects_root.
>>
>> If gitweb is configured to scan for repositories, adding existing git
>> repository to gitweb doesn't make sense.  If gitweb is configured to
>> use static file with list of repositories, of course it would make
>> sense... but then the question is how would one specify location of
>> a new repository to add.
> 
> How about like this ?
> We will have a static file with list of projects. All the repositories
> in scan path will be added to this list. Then we will also have an
> option to add an existing repository which can be done when the user
> specifies a relative or full path to the repository.

>>> Yes. I will not be doing it in GSoC and it won't be a part of gitweb, But I
>>> hope to provide an authentication wrapper for gitweb in future.
>>
>> Well, unless there would be time for it after you finish all other work,
>> but it is a bit unlikely.
> 
> I don't think so. I would like to constantly contribute to gitweb.

> On Mon, 19 April 2010, Pavan Kumar Sunkara wrote:
>> 2010/4/19 Jakub Narebski <jnareb@gmail.com>:
>>> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote:
>>>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>>>
>>> I can agree that you would be able to learn Perl in a week.  I do not
>>> think however that you can become proficient in Perl (and neither in any
>>> other non-trivial programming language) in such short time.  The question
>>> remains if you can be proficient enough for the task in question...
>>
>> I can learn perl in 3 hours. Becoming proficient in perl is just
>> knowing about all the majorly used inbuilt functions and libraries.
>> Coming to the concepts of programming, I already know a lot about it
>> along with data structures and algortihms. So you need not doubt me on
>> this.
>
> You can (probably) learn Perl *syntax* in 3 hours.  You perhaps can
> learn to start to write clean, idiomatic Perl within a week, provided
> that you find good books (like "Higher-Order Perl", which can be found
> at http://hop.perl.plover.com/book/, or other Perl books from O'Reilly).
> Be proficient in Perl in that short time?  I don't think so.
>
> I guess that you can learn enough Perl for this project, but I'd really
> prefer for you to be proficient in Perl already...

>>>
>>> Yes, I found it in later parts of proposal, but don't you think that
>>> this goal of this project should be stated upfront, so that one can
>>> know what this project is to be about from project description itself?
>>
>> I thought it should be described later in the "Describe your project
>> in more detail" section.  So, I didn't go into details here.
>
> Nevetheless it is a place to describe *specific* goal of project here,
> in one to two sentences.  No marketing buzzwords here :-PPP

>>>
>>> I guess (please correct me if I am wrong) that lib/ would contain modules
>>> *required* by gitweb, and modules/ would contain *optional* modules
>>> needed for extra functionality (for extra features).
>>
>> You are half correct.
>> lib/ contains modules *required* by gitweb
>> modules/ contains actions *performed* in gitweb like commitlog,
>> snapshot etc.. (write actions too)
>>
>> Maybe I will rename it to actions/ to not to be confused.
>
> I don't understand why actions are not to be in lib/, like e.g. SVN::Web
> (http://p3rl.org/SVN::Web) has SVN::Web::Blame module for 'blame' action?
> Although I am not sure if SVN::Web is a good example of coding practices
> and code organization.

>>>
>>> If gitweb is configured to scan for repositories, adding existing git
>>> repository to gitweb doesn't make sense.  If gitweb is configured to
>>> use static file with list of repositories, of course it would make
>>> sense... but then the question is how would one specify location of
>>> a new repository to add.
>>
>> How about like this ?
>> We will have a static file with list of projects. All the repositories
>> in scan path will be added to this list. Then we will also have an
>> option to add an existing repository which can be done when the user
>> specifies a relative or full path to the repository.
>
> O.K. that is a good idea: make gitweb scan for repositories, and present
> user with the list of them to add to static list of visible projects
> (repositories).

>>>
>>> Well, unless there would be time for it after you finish all other work,
>>> but it is a bit unlikely.
>>
>> I don't think so. I would like to constantly contribute to gitweb.
>
> I'm sorry, we seem to have a bit of misunderstanding here.  What I meant
> that this should be in the "optional" part of GSoC project, so it would
> be worked on during GSoC only after everything else is done.  Because the
> scope of this project is quite wide, I though it unlikely to have time
> left at the end of GSoC after finishing all other more important features.
>
> I did not mean to say that you would be unlikely to contribute after GSoC
> finishes.