Re: GSoC 2010: "Integrated Web Client for git" proposal

[Pavan Kumar Sunkara <pavan.sss1991@gmail.com>]

On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis <pasky@suse.cz> wrote:
> 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.

Yes, I promise that I will try my best to submit patches early and try
to get them merged them into mainstream.

>>    * 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?
>

Session management reduces the length of URL and templating reduces
the amount of HTML in the actual code.

>> 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].

[8] includes creating and deleting branches along with listing and
switching where as [11] includes just switching and also allows to
switch between commits and tags.

>
>>  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.

>>   3. List all the commits with pagination [git log]
>
> Why?

It's nothing but the current gitweb does.

>
>>   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?

Yes

>
>> 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.).

Yes.

>> 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.

We haven't yet decided on how to split gitweb, so I would like to give
a bit more details about this after I take the majority opinion on how
to split gitweb.

>
>> [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.
>

I don't think so. Anyway, let's try it. :-)

> --
>                                Petr "Pasky" Baudis
> http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
>

Please ask me if you have any other doubts regarding this proposal.

Thanks
-pavan