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

On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis [off-list ref] wrote:

Thanks for work on the proposal!

On Sun, Apr 18, 2010 at 02:22:20PM +0530, Pavan Kumar Sunkara wrote:

quoted

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.

quoted

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

quoted

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.

quoted

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.

quoted

 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.

quoted

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.

quoted

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

Why?

It's nothing but the current gitweb does.

quoted

  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

quoted

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.

quoted

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!

quoted

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

quoted

[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