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

  Hi!

On Thu, Apr 22, 2010 at 02:19:02AM +0530, Pavan Kumar Sunkara wrote:

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

  (I have reservations to this particular structure and naming, but I
don't think that's crucial for the proposal.)

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.

Sounds fine in principle.

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.

I will be using a static
file to maintain the list of repositories which is obtained by
scanning repositories.

Will this be compatible with the current project list file?

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

BTW, I think you could prioritize better, e.g. (5) or (10) is rather
minor thing while (11) or (14),(15) are crucial. But this is not that
important if you are confident you will finish everything listed. ;-)

* - Merging two branches can be quite complicated. Simple merge
mentioned above will be just showing you that there are conflicts. But
you won't be having options to

BTW, I don't think it's really complicated at all in the simple conflict
case - just edit the file and do git add (getting all the file-directory
etc. cases right might be more tedious, but less important).

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.

Good work, I like this better than the first proposal. :-)

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