GSoC 2010: "Integrated Web Client for git" proposal

GSoC 2010: "Integrated Web Client for git" proposal

[Christian Couder]

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.

Best regards,
Christian.


 

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

[Jakub Narebski]

Dnia czwartek 15. kwietnia 2010 06:30, Christian Couder napisał:
> 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/

I would really prefer if Pavan just *wrote* the text of his "Integrated
Web Client for git" proposal for GSoC 2010 in email, instead of providing
link to it; link that requires signing-in.

  This proposal aims at creating a multi-purpose HTML based GUI client
  for git. This client intends in reducing the work needed to be done
  by a developer while working on a git repository. This is not another
  gitweb or gitorious but it also contains their functionalities as
  submodules.
 
  The project goal is to try and implement a integrated multi-purpose
  HTML based GUI client for git. It contains two parts which are
  crucial while working on a git repository, Read and Write.

    * Read means browse through the code and repository
    * Write means working on the code and repository

  Also, in the future others will be able to develop more functionalities
  for this client with the help of the framework like structure of this
  project.

It is not entirely sure what this "Web Client" is meant to do.  Is it
mainly meant as web interface to managing repositories (webmin for git),
something that GitHub, Gitorious, InDefero, Girocco all include?  This
could mean web interface to configuring gitosis / gitolite.  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?  Or is it something else?

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

It could be a waste to duplicate functionality that is already present
in gitweb, at least for GSoC (having yet another web interface for git,
this time in Python, could be a good thing... if the web interface would
be developed further). 

As to integrating "Web Client for Git" with gitweb, there exists at least
a few possible ways to do this:

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.

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.

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

True, I don't think that e.g. git.kernel.org or repo.or.cz could install
Catalyst and Git::PurePerl and use Gitalist instead of gitweb...

P.S. If I remember correctly Gitalist was based out of last gitweb version
     before it got bundled with git.  I wonder if they caught up to the
     modern gitweb features (snapshots, Atom/RSS feeds, basic submodule
     support, handling images, incremental blame, grep and pickaxe search,
     etc.).

-- 
Jakub Narebski
Poland

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

[Petr Baudis]

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.

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

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

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

[Jakub Narebski]

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

Well, you can always add some of "Web Client" functionality directly
to gitweb (for example dispatch must be, I think, in gitweb).  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).

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


BTW. the major thing that prevented me from using Git.pm was the few
places that gitweb uses pipeline, or needs to redirect STDERR to 
/dev/null.  Also t9700-perl-git.sh test doesn't test command_output_pipe
and the like. 

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

-- 
Jakub Narebski
Poland

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

[Petr Baudis]

On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:
> 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?)?

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

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

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

[Pavan Kumar Sunkara]

Here is my rewritten proposal as Christian and Petr asked me to write.
Please go through this.

Thanks

-pavan

=====================================================

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
gitweb along with it's browsing functionalities. It also aims at
splitting and organising the structure of gitweb perl script.

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.

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.
   * It should be possible that the new gitweb requires less time to
work on a git repository than any other git client.
   * User friendly graphical interface with smart UI design when
compared to any other git clients or browsers.

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]
 15. Search for a part of code [git grep]

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

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

e) Future functionalities:

   * Implementing a file editor
   * Rebasing branches
   * Content History browser - (The gsoc 2010 idea in wiki)
   * Implementing git bisect
   * Cherry picking
   * Patches management along with email
   * Viewing git stats in an interactive user interface
   * Developing API to work with gitweb for storing information in
form of a git repository

If completed properly, this is going to be a combination of gitk,
git-gui and gitweb, giddy, git-age and other git tools into a great
code. Many of the current git users are dissatisfied with current git
clients and have always been complaining about them in the IRC. Also
some of them complain about the complexity of installation of gitweb.
This project will solve both the problems.

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.

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.


TimeLine

I strongly believe in Agile methodology and stick to it. Agile
practices make all the more sense in open source projects like Git,
where the features are added/modified on the basis of the user's
feedback. We should have the ability to swiftly modify the product or
feature on the basis of the feedback from the community.

The following gives a brief idea about the iteration cycle that I'll
be following during the development period: The iteration cycle is of
1 day duration

   * Discuss the deliverables for the next iteration with the mentors
along with my daily report.
   * Work on the implementation and send patches on implemented
functionality in email to developers mailing list.
   * The developers and the mentors review it and try to merge it upstream
   * Fix bugs, tweak UI etc depending on the feedback. Also document
everything while its still fresh in my mind.

[Prior May 24]
Read and understand the code of current gitweb. Install it and play with it.

[May 4th week - June 1st week]
Split the whole code of gitweb into framework structure and setup
library files along with installation and configuration.

[June 2nd week]
Move the read modules accordingly

[June 3rd week]
Complete module from W1 to W3

[June 4th week]
Complete modules from W4 to W7

[July 1st week]
Complete module W8 and W9

[July 2nd week]
Check for any possible and potential security loopholes or bugs

[July 3rd week]
Complete modules W10 and W11

[July 4th week]
Complete modules W12 and W13

[Aug 1st week]
Complete mdoules W14 and W15

[Aug 2nd week]
Scrub code, Improve Documentation and last minute touches

-- W means write modules


About Me

I am an Indian student, doing my Bachelor's Degree in Computer Science
and Engineering at IIT Madras, one of the top Universities in the
World. I beleive I am a fast learner and have learnt most of the
famous programming languages in the coding world. I am 19 years old
and have a keen interest in field of Game programming.

1. Open Source Experience

Open Source Experience is one thing which everyone requires if he want
to participate in Google Summer of Code. We need to have knowledge of
version control systems, such as SVN, GIT etc.. . Also they need to
follow the standard coding pratices and methods either given by the
project members or community. Theys should also be able to communicate
well. I believe I have all these mentioned qualities and have a keen
interest in field of OpenSource programming.

* LimeSurvey
LimeSurvey is self-described as the 'leading open source tool for
online surveys', which probably isn't much of an exaggeration. I have
already submitted many patches for bugs and committed a few changes
myself

* Charty - Google Wave Gadget
It is a Google Wave gadget for embedding interactive charts and
graphs. It uses methods like Google Wave API, XML, JSON and
javascript. It's source is made open for all.

* BBGFramework
Contributed to the open source PHP5 based Browser Based Gaming
framework by adding installation package and fixing bugs.

* Hackerz
It is an open source Hacking simulation game written in java and
currently in very early stage with short source control history.

2. Coding Expereince

There are more to my experience in programming than the ones listed in
above section. They all are in different languages of programming.

* My Sport Club Manager - Browser Based Game
It is browser based Ice hockey simulation game that runs on PHP and
mysql and uses other web technologies like AJAX and javascript
libraries like prototype. Designed a game flow and a database
structure and implemented the same. It offers a rich gameplay where
clubs can be managed with parameters like stadium, tactics, formation,
finance, stats etc.. A runtime commentatory is genertated
encapsulating all important movements of the game simulation.

* Web related works
     Created a PHP based file system Database and Query Language for
small scale database applications.
     Designed and developed a fully valid CSS for wordpress, the
famous blogging platform.
     Developed a single page forum script to avoid space issues and
optimized database calls to reduce the execution time unlike the
traditional bulky forums.
     Incorporated a web-based application that offers flexibility in
presentation of the information to generate a structured resume
following pre-defined document standards

* Non-web related works
     Designed and implemented an 8 bit micro-processor using Verilog, a HWDL
     Developed an IRC bot for listening and logging a particular
channel given the required details.
     Developed an AI for 'Dots and Boxes' game in Java.
     Designed and developed a small TicTacToe Network game server and
client in Python

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

I believe in taking initiatives and executing them. I have a natural
aptitude for technology as demonstrated by my numerous innovative
endeavors. I believe I am ambitious, creative and hardworking which
makes me an asset for any organization/team.

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.

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

[Jakub Narebski]

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.

>   8. Switch branches [git branch]

You would probably want creating new branches here, too.

>   9. A simple branch merging* [git merge]

Do you mean here by "simple" merge that does not lead to merge 
conflicts?

>  10. Creating tags [git tag]

O.K.  Does it include creating signed tags?

>  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

GSoC 2010: "Integrated Web Client for git" proposal

[Pavan Kumar Sunkara]

On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> 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).
>

I don't know perl but learning it an d 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.

>
> 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's an error with my grammar. I actually mean to concentrate on "edit" part.
I am not a native english speaker. So, there might be problems with my grammar.

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

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

Yeah, you are right but I would like to give some introduction.

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

Yes.

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

Sorry again. As I said, I am not very good in english. I can just communicate.

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

Yeah.

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

yes. I mean it.

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

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

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 ?

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

Sorry. I forgot to mention them.

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

As i said above, I would like to take the majority opinion on how to
split gitweb.

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

Sorry for my grammar.

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

I would like it to run new gitweb 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.
>

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.

>
> > 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 will be just a string substitution by a small templater class.

>
> > 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 basic library files like errorhandlers, session manager,
templater, redirecter, Gitweb::Utils and Gitweb::repo etc..

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

Thanks.

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

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

When used as a client, it will be cloning from a URL. right ?

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

All the above actions will have link from git status view.

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

As I said above, it will be available to commit from git status view.

>
> >   8. Switch branches [git branch]
>
> You would probably want creating new branches here, too.

Yeah, I mean it.

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

It can lead to merge conflicts but what I mean is you cannot solve it
from the client.

>
> >  10. Creating tags [git tag]
>
> O.K.  Does it include creating signed tags?

Yes.

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

Yes. Sorry for repeating it.

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

I think i missed that point. all functionalites with "git remote" will
be added too.

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

Nice idea.

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

I want to include this so that in future it can integrated with
pickaxe interface.

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

Yes. i will just copy the code from the current 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.

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.

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

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.

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

I already answered it. :-)

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

I use this sentence on others and now you are using it on me :-)
Sorry for including them. I thought that they are important for this
project so I included the too.

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

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

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

[Jakub Narebski]

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?  

Anyway I'd rather you put it in "if I have time" pile...

-- 
Jakub Narebski
Poland

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

[Pavan Kumar Sunkara]

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

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.

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

Sorry about that.

I have already given my idea in the proposal. I would like to hear
your opinions and implement the majority opinion if my  idea is full
of flaws. That is what I meant by the line.

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

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

OK.

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

Ok. If everyone feels the same I would like remove it from the proposal.

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

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

Yeah, we have already discussed about it in previous mails. The final
conclusion is not to use session manager in gitweb. But let's include
a module for it so that it can be used when others build
authentication support.

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

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.

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

Yes, it wouldn't need authentication because the server will be 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.

I don't think so. I would like to constantly contribute to gitweb.

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

Yes, Exactly.

> Anyway I'd rather you put it in "if I have time" pile...

Yes, I already mentioned it in the proposal. It is under the section
"Future functionalities"

-pavan

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

[Jakub Narebski]

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:

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

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

Nevetheless it is a place to describe *specific* goal of project here,
in one to two sentences.  No marketing buzzwords here :-PPP
 
[...]
>>>>>    * 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.

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.

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

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

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

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.
 
-- 
Jakub Narebski
Poland

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

[Pavan Kumar Sunkara]

On Tue, Apr 20, 2010 at 4:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> 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...

It's your choice. All I can say is learning perl won't be a
obstruction to do this project.

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

I did so to make them clearly distinct and easily to be maintain and
modify later.

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

ok.

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

ok. I can include it is an option part of GSoC.

Thanks
-pavan

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

[Petr Baudis]

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?

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

Why?

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

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

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

[Pavan Kumar Sunkara]

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

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

[Matthieu Moy]

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
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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.

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.

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.

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

[Pavan Kumar Sunkara]

On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Yeah, I agree to that.

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

Sorry but I don't know what it is.
The current average git used are in need of a git client and git-gui
is not doing a good job of it. So, this proposal solves it by
providing client features inside gitweb itself. :-)

-pavan

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

[Petr Baudis]

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.

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

I think it will be best to discuss session support (and work on
implementing it) when actual features where it is essential will
come up. So far, I'm unable to foresee them, but if we discuss it
later in conjunction with some concrete features, perhaps it will
be clearer.

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

I think that would be something entirely different, and IMO even
much less interesting. ;-)

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

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

[Matthieu Moy]

Petr Baudis <pasky@suse.cz> writes:

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

One use-case I'd like this work to be able to address is:

Many of my colleagues don't want to use Git. If I send them a mail
with the cut-and-paste-ready "git clone" command, they'll still reply
asking for an attachment to an email, and they'll send me their
modifications the same way.

In a good write-enabled web interface, they'd browse the repository
online, pick a file, and the download page would point them to a URL
containing the filename, and the base commit, with a form to upload a
new version of the file.

Some time later, they could re-use the same URL, and upload the
modified version of the file. Actually, I could even do the first step
myself, and send them an email with the attachment and the URL, and
they'd upload their version whenever they want. The upload should
create a commit in a separate branch, starting from the base commit
contained in the URL. I could do the merge myself later in case of
non-fast forward.

That's a real senario, and I believe it would be a rather common
use-case of a web-based git client: a power-user prepares the work,
and sends well-prepared URL to newbies. This really requires GET
parameters.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Pavan Kumar Sunkara]

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 ?

-pavan

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

[Matthieu Moy]

Pavan Kumar Sunkara <pavan.sss1991@gmail.com> writes:

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

That doesn't seem contradictory. You can have login/password as
cookies or session variables, and other parameters within the URL.

Then, if I send you a URL pointing to a write-enabled page which
requires authentication, and you click it, you'll be prompted for your
login/password before you can proceed, but after that, you'll still be
redirected to the right page.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Petr Baudis]

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?

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

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

[Pavan Kumar Sunkara]

Sorry for late reply, I actually skipped this mail.

2010/4/19 Petr Baudis <pasky@suse.cz>:
> 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.

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.

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

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.

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

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.

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

Thanks
-pavan

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

[Petr Baudis]

On Mon, Apr 19, 2010 at 11:40:33PM +0530, Pavan Kumar Sunkara wrote:
> 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.

Aha, I see. I will be curious what you come up with. :-)

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

Ok!

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

See one of other Jakub's mails for examples of commands to be used.
If you have more specific questions, feel free to follow up.

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

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

[Jakub Narebski]

On Sun, Apr 18, 2010, Petr Baudis wrote:
> On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:
>> 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?)?
> 
>   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.

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

I guess that git-gui and gitk duplicate some of their functionality
(and only git-gui is split; gitk is monolitic single file, even larger
than gitweb: 320KB vs 220KB).

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

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

True.

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

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.

There are quite a few requirements that gitweb should fulfill:
* It must be able to install without admin rights, and requirng to
  install Perl modules system wide.  We can rely on core Perl modules,
  on git core and possibly on perl-Git being installed.
* It must be able to install without editing web server config file,
  nor setting environment variables for the user account that is used
  by the web server (e.g. 'apache', or 'web', or 'nobody').
* Possibly also it should be easy to install gitweb "by hand", without
  requirng to use build system.
* Any automatic installation target must take into account that gitweb
  must run on many web servers (Apache as CGI, Apache as mod_perl, nginx,
  lighttpd, IIS, Moongose, Webrick,...) and on many distributions and
  operating systems (where location of server, and server configuration
  might differ).  But I guess we can borrow some code from git-instaweb.sh


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)

-- 
Jakub Narebski
Poland

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

[Petr Baudis]

On Sun, Apr 18, 2010 at 07:50:17PM +0200, Jakub Narebski wrote:
> 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.
But it needs to be coded so that it does not require an actual checked
out copy (which shouldn't be too much hassle).

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

I would prefer the do. :-)

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

Oops, sorry. I meant that it should be really only last result if we try
to split things and for some reason it keeps not working out.

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

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

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

[Jakub Narebski]

On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:
> On Sun, Apr 18, 2010 at 07:50:17PM +0200, Jakub Narebski wrote:

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

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

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

Let's check what gitweb/INSTALL says currently

        $ make prefix=/usr gitweb             ;# as yourself
        # cp gitweb/git* /var/www/cgi-bin/    ;# as root

WTF with 'gitweb/git*' glob?  

Ah, later there is "Build example", which is

 - To install gitweb to /var/www/cgi-bin/gitweb/ when git wrapper
   is installed at /usr/local/bin/git and the repositories (projects)
   we want to display are under /home/local/scm, you can do

        make GITWEB_PROJECTROOT="/home/local/scm" \
             GITWEB_JS="/gitweb/gitweb.js" \
             GITWEB_CSS="/gitweb/gitweb.css" \
             GITWEB_LOGO="/gitweb/git-logo.png" \
             GITWEB_FAVICON="/gitweb/git-favicon.png" \
             bindir=/usr/local/bin \
             gitweb

        cp -fv ~/git/gitweb/gitweb.{cgi,js,css} \
               ~/git/gitweb/git-{favicon,logo}.png \
             /var/www/cgi-bin/gitweb/

WTF with '~/git/gitweb'... ehh, that one is mine, I guess...


So additional step would be

        cp -fvR gitweb/lib /var/www/cgi-bin/    ;# as root


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

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

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

-- 
Jakub Narebski
Poland

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

[Petr Baudis]

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

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

[Pavan Kumar Sunkara]

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

Yes, you can see it in "future functionalities" section of the proposal.

Implementing a proper and perfect file editor will be a tough job. So,
I removed it from GSoC and listed in that section.
But we can always have a simple textarea to implement it and I think I
will have time to do this simple textarea during my GSoC.

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

We can try it. :-)

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

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

[Petr Baudis]

On Mon, Apr 19, 2010 at 11:33:49PM +0530, Pavan Kumar Sunkara wrote:
> Implementing a proper and perfect file editor will be a tough job. So,
> I removed it from GSoC and listed in that section.
> But we can always have a simple textarea to implement it and I think I
> will have time to do this simple textarea during my GSoC.

Of course we meant just plain textarea, I think that's more than enough.
I think this would be rather important part of the project.

For later, there's also plenty of javascript editors available that can
be used as drop-ins, though I'm not sure if any of them is programming
oriented. At any rate, I don't see why text editor like this would be
gitweb-specific.

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

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

[Jakub Narebski]

On Mon, Apr 19, 2010, Petr Baudis wrote:
> 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.

At the end, in the section which describes what would be not included
in the project, there was editing files excluded from project.

Which is a bit strange because you need some kind of web editor (even
if it is simply textarea) for the commit message if this "Web Client"
is to implement [git commit]...
 
>>> 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.

What do you mean here by "working tree - index dichotomy"?
 
>> 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.

It is not that difficult.  You can use IPC::Open2 (which is in core)
and IO::Handle (for easier coding; using IO::Handle is not strictly
necessary), like that:

  use IPC::Open2 qw(open2);
  use IO::Handle;

  ...

  my $pid = open2($out, $in, git_cmd(), 'hash-object', '-w', '--stdin');
  $in->printflush($cgi->param('textarea'))
     or die...;
  my $sha1 = $out->getline();
  chomp $sha1;

  close $out;
  waitpid $pid, 0;

Then you would need:

  system(git_cmd(), 'update-index', '--cacheinfo',
         '100644', $sha1, $pretend_path)
    or die...;

Not tested!
-- 
Jakub Narebski
Poland

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

[Pavan Kumar Sunkara]

Hi,
 According to advice from Christian and Petr, Here is my updated GSoC
proposal which has been a result of all the discussions in this
thread.
Thanks

-pavan

=====================================================

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 modules. Not only providing the browsing
functionalities in gitweb, but it also aims at developing
functionalities for working on a git repository.


Project Goals

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.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.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. The lib directory will also contain
some basic modules like Gitweb::Repo, Gitweb::Commit which will make
developing further functionalities easier. The write actions need not
be working in a gitweb installation like repo.or.cz, so we will also
have an option to disable the write modules. I will be using a static
file to maintain the list of repositories which is obtained by
scanning repositories.

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

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

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

e) Future functionalities:

   * Rebasing branches
   * Content History browser using pickaxe
   * Implementing git bisect
   * Cherry picking
   * Patches management along with email
   * Viewing git stats in an interactive user interface
   * Developing some kind of REST API to be used from other clients
for storing information in form of a git repository

If completed properly, this is going to be a combination of gitk,
git-gui and gitweb, giddy, git-age and other git tools into a great
code. Many of the current git users are dissatisfied with current git
clients and have always been complaining about them in the IRC. Also
some of them complain about the complexity of installation of gitweb.
This project will solve both the problems.

I don't know perl but I can learn it's syntax in less than a day and
as I know the concepts of programming I will try to become proficient
in perl starting from May 3rd.

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.

I agree that as soon as the GSoC really starts, time for abstract
planning and discussing should be mostly over. I will be ready to
code, create patches, even if only RFC patches, send them to the list,
and then discuss them, reply to reviews, improve them and resend and
try my best to merge them upstream.

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.


TimeLine

I strongly believe in Agile methodology and stick to it. Agile
practices make all the more sense in open source projects like Git,
where the features are added/modified on the basis of the user's
feedback. We should have the ability to swiftly modify the product or
feature on the basis of the feedback from the community.

The following gives a brief idea about the iteration cycle that I'll
be following during the development period: The iteration cycle is of
1 day duration

   * Discuss the deliverables for the next iteration with the mentors
along with my daily report.
   * Work on the implementation and send patches on implemented
functionality in email to developers mailing list.
   * The developers and the mentors review it and try to merge it upstream
   * Fix bugs, tweak UI etc depending on the feedback. Also document
everything while its still fresh in my mind.

[Prior May 24]
Read and understand the code of current gitweb. Discuss with mentors
and finish abstract planning.

[May 4th week - June 1st week]
Split the whole code of gitweb into proposed structure and setup
library files along with installation and configuration.

[June 2nd week]
Move the read modules accordingly

[June 3rd week]
Complete module from W1 to W3

[June 4th week]
Complete modules from W4 to W7

[July 1st week]
Complete module W8 to W10

[July 2nd week]
Check for any possible and potential security loopholes or bugs

[July 3rd week]
Complete modules W11 and W12

[July 4th week]
Complete modules W13 to W15

[Aug 1st week]
Complete mdoules W16 and W17

[Aug 2nd week]
Scrub code, Improve Documentation and last minute touches

-- W means write actions


About Me

I am an Indian student, doing my Bachelor's Degree in Computer Science
and Engineering at IIT Madras, one of the top Universities in the
World. I beleive I am a fast learner and have learnt most of the
famous programming languages in the coding world. I am 19 years old
and have a keen interest in field of Game programming.

1. Open Source Experience

Open Source Experience is one thing which everyone requires if he want
to participate in Google Summer of Code. We need to have knowledge of
version control systems, such as SVN, GIT etc.. . Also they need to
follow the standard coding pratices and methods either given by the
project members or community. They should also be able to communicate
well. I believe I have all these mentioned qualities and have a keen
interest in field of Open Source programming.

* LimeSurvey
LimeSurvey is self-described as the 'leading open source tool for
online surveys', which probably isn't much of an exaggeration. I have
already submitted many patches for bugs and committed a few changes
myself

* Charty - Google Wave Gadget
It is a Google Wave gadget for embedding interactive charts and
graphs. It uses methods like Google Wave API, XML, JSON and
javascript. It's source is made open for all.

* BBGFramework
Contributed to the open source PHP5 based Browser Based Gaming
framework by adding installation package and fixing bugs.

* Hackerz
It is an open source Hacking simulation game written in java and
currently in very early stage with short source control history.

2. Coding Expereince

There are more to my experience in programming than the ones listed in
above section. They all are in different languages of programming.

* My Sport Club Manager - Browser Based Game
It is browser based Ice hockey simulation game that runs on PHP and
mysql and uses other web technologies like AJAX and javascript
libraries like prototype. Designed a game flow and a database
structure and implemented the same. It offers a rich gameplay where
clubs can be managed with parameters like stadium, tactics, formation,
finance, stats etc.. A runtime commentatory is genertated
encapsulating all important movements of the game simulation.

* Web related works
     Created a PHP based file system Database and Query Language for
small scale database applications.
     Designed and developed a fully valid CSS for wordpress, the
famous blogging platform.
     Developed a single page forum script to avoid space issues and
optimized database calls to reduce the execution time unlike the
traditional bulky forums.
     Incorporated a web-based application that offers flexibility in
presentation of the information to generate a structured resume
following pre-defined document standards

* Non-web related works
     Designed and implemented an 8 bit micro-processor using Verilog, a HWDL
     Developed an IRC bot for listening and logging a particular
channel given the required details.
     Developed an AI for 'Dots and Boxes' game in Java.
     Designed and developed a small TicTacToe Network game server and
client in Python

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
   * Basic Graph Theory

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
   * C
   * C++
   * Java
   * Verilog
   * Assembly language

I believe in taking initiatives and executing them. I have a natural
aptitude for technology as demonstrated by my numerous innovative
endeavors. I believe I am ambitious, creative and hardworking which
makes me an asset for any organization/team.

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.

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

[Petr Baudis]

  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

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

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.

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

[Petr Baudis]

On Thu, Apr 22, 2010 at 02:15:32PM -0700, Junio C Hamano wrote:
> 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?

  Currently, the write side will probably not be able to work on bare
repositories; it will have a working copy _per repository_ and the
operations like git add will work on the working copy.

  The original idea was to just have a git-gui replacement that runs
within your browser, and that's what is getting implemented I think.
This is not that interesting to me, but the applications it can be
easily extended to are. ;-)

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

  DeltaV?

  I think WebDAV API would be very fine to have *in addition* to
user-friendly web interface, but is useful in very different scenarios.
You need something to frontend WebDAV anyway.

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

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>   The original idea was to just have a git-gui replacement that runs
> within your browser, and that's what is getting implemented I think.

Ok.

>   I think WebDAV API would be very fine to have *in addition* to
> user-friendly web interface, but is useful in very different scenarios.
> You need something to frontend WebDAV anyway.

There are different "useful" projects that can happen in this area:

 - a project to create a general front-end to versioned WebDAV; or

 - a project to serve git repository to such front-end implementations; or

 - a project to build an ad-hoc "git only" system.

The first one doesn't have to be within the purview of the "git" project
per-se, and it can presumably work against anybody's versioned WebDAV
server implementation (e.g. RFC 3253).

The second one would be to build one such server.  It would be quite
specific to, hence suitable to be supported by, the "git" project.

The third?  It may look like a simplest way to get a working system, but
I see at least two downsides:

 - designing server-side working tree right is not trivial.  I don't know
   if existing proposed standard matches the semantics git users expect
   from the versioning system well, but I would expect that it would be a
   far better starting point to use than coming up with a random ad-hoc
   semantics in a hurry.

 - in the end, the users will be tied to one implementation of the server
   and the client (they are pretty much the same single ball of wax under
   the current proposal, no?).

You can punt by choosing not to do a per-client server-side working tree
and reduce the problem complexity somewhat, but at that point we will be
looking at a single-user ad-hoc system; it doesn't interest me very much,
personally [*1*].

[Footnote]

*1* It doesn't necessarily mean I'd vote the proposal down (git is not my
personal project)---it just means I wouldn't vote _for_ it.

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

[Pavan Kumar Sunkara]

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

Yeah sure.

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

I am not planning to write the "operation mode without working copy"
during GSoC due to reasons I mentioned earlier. But I would like to
add it as an optional part for GSoC along with the authentication
wrapper.

So, When I complete the main parts of my GSoC proposal, you will be
able to use it in your localhost working on your local repos. If I
have time during GSoC I will complete the auth wrapper and "without
working copy" mode. Otherwise I will develop them after GSoC. Then you
can use the write functionalities in repo.or.cz without actual working
copies. :-)

Thanks
-pavan

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

[Christian Couder]

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.

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

[Pavan Kumar Sunkara]

On Fri, Apr 23, 2010 at 10:57 AM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> 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.

Thanks. As I said before, Sorry for my grammar.

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

Yeah, I am planning to do that. :-)

Thanks
-pavan