From: Christian Couder <hidden> Date: 2016-06-15 22:48:37
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.
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:40
On Sun, Apr 18, Petr Baudis wrote:
On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
quoted
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?)?
quoted
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.
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:
On Sun, Apr 18, Petr Baudis wrote:
quoted
On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
quoted
quoted
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.
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.
quoted
quoted
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
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.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:40
On Sun, Apr 18, 2010, Petr Baudis wrote:
On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:
quoted
On Sun, Apr 18, Petr Baudis wrote:
quoted
On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
quoted
quoted
quoted
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...
quoted
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).
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`).
quoted
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.
quoted
quoted
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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).
quoted
quoted
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.
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:40
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.
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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
On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis [off-list ref] wrote:
Thanks for work on the proposal!
On Sun, Apr 18, 2010 at 02:22:20PM +0530, Pavan Kumar Sunkara wrote:
quoted
2.How would you measure its success or failure?
There are two parameters which would majorly determine the success or
failure of the project.
* Splitting gitweb such that there should be no problem with the
installation of gitweb across cross servers and cross systems.
I believe an important factor in the success of the project is getting
these changes merged upstream in the main Git branch.
If the rest of the project features is not merged (and it *won't* be for
the lack of trying), it will still be reasonably easy to use it as a
third-party modification. However, if the split-up itself will not be
merged, that will have big impact on the usefulness of the whole project
- so I consider this fairly crucial, please don't under-estimate this
part, getting things merged can take as much work as doing initial
implementation of the stuff! You should plan to submit these patches
quite early.
Yes, I promise that I will try my best to submit patches early and try
to get them merged them into mainstream.
quoted
* It should be possible that the new gitweb requires less time to
work on a git repository than any other git client.
I'm sorry, I don't understand this.
quoted
3.Describe your project in more detail.
I would like to split the currently 6800 long piece of code in
gitweb.pl perl script into small files which will result in better
readability, maintainability and modifiability. The file structure of
the new gitweb is given below and I will explain the working after it.
(From now on, I would like to call the actions of gitweb as modules of gitweb)
a) File Structure:
* gitweb.pl -- Main script parsing urls and calling required modules
* gitweb.tpl -- The template of the web page (GUI) in which
modules are embedded
* gitweb.css -- The style for the gitweb pages.
* gitweb.js -- javascript to make gitweb more interactive
* modules (dir) -- directory containing the write and read modules.
* lib (dir) -- some basic files like config, error_handler,
templater, redirecter, htmlHelper etc..
The current gitweb makefile makes a gitweb.cgi from the perl script
and requires apache or lighttpd server for it's working. I would like
to continue this process but the change will be in the gitweb perl
script. The new script includes config and other basic files, checks
the URL, parses it, detects the module, manage session and includes
the proper module. It then retreives the output of the module and
substitutes it with the gitweb.tpl template file string and gives out
a proper HTML, CSS web page. It also contains some basic library files
in the lib directory. The new gitweb uses session variables to track
some of the variables rather than including them in the url. The write
modules need not be working in a gitweb installation like repo.or.cz,
so we will also have an option to disable the write modules.
Frankly, I'm not very excited from this. First, I recommend that you
completely separate splitting of gitweb to smaller pieces (without any
major conceptual changes) both in the proposal and in actual
submissions.
Second, you should justify the introduction of session management and
templating. What is the point and why is it neccessary for your project
goals?
Session management reduces the length of URL and templating reduces
the amount of HTML in the actual code.
quoted
b) Write modules of the client:
1. Add Existing repositories to the gitweb -- This will list the
given repo into gitweb config
2. Create new/Clone repositories into a given path [git init | git
clone] -- This will create new repo and list it
3. Add/Remove/Move files [git add | git rm | git mv]
4. Stage/Unstage files [git add | git reset]
5. Add files to ignore list when u click on 'Ignore' link
6. Discard changes to a file in working copy [git reset]
7. Commit to the repository with a log message and an optional
sign-off [git commit]
8. Switch branches [git branch]
9. A simple branch merging* [git merge]
10. Creating tags [git tag]
11. Checkout code to a specific commit or branch or tag [git checkout]
12. Push to a remote branch [git push]
13. Fetch/Pull from a remote branch [git fetch | git pull]
14. Garbage collection [git gc]
Sounds reasonable. What am I missing is a way to edit files through the
web interface. Also, please spec in more detail the difference between
[8] and [11].
[8] includes creating and deleting branches along with listing and
switching where as [11] includes just switching and also allows to
switch between commits and tags.
quoted
15. Search for a part of code [git grep]
This is already supported by gitweb. And it's not a "write" operation.
;-)
I wrote it here because I would like to integrate it with content
history browser functionality later.
quoted
c) Read modules of the client: (most of this need not be written, just
need to be organised)
1. See the status of repository [git status]
How will you integrate this with the existing 'tree' action?
No, there will be a seperate page for it which executes git status command.
quoted
3. List all the commits with pagination [git log]
Why?
It's nothing but the current gitweb does.
quoted
4. With every commit we can
* Visualise trees [git ls-tree]
* Visualise files and diffs [git show]
* Visualise annotations [git blame]
5. List all branches including remote ones [git branch]
6. Search commits, branches, authors etc..
I.e. what we already do?
Yes
quoted
d) Usage of the client:
* Install on intranet - A company when installs this gitweb along with
some other login and account managing scripts will be able to order
their employees to login and ask them to work on the code with out the
security risk of providing ssh access to the git repository host.
Frankly, the net security risk of providing git-shell access is probably
lower than using a web interface. ;-) However, I still see this making
many corporate people happy and opening doors to less canonical Git
usecases - it also enables "zero config" ability to contribute to Git
projects, desirable for less technical users (artists etc.).
Yes.
quoted
I will try to make sure that the patches to be as small as possible
and easily reviewable. Also my vacation starts on May 2nd and ends on
August 1st. So most of the project work will be done during the start
of the GSoC project rather than in the end.
Great!
quoted
[May 4th week - June 1st week]
Split the whole code of gitweb into framework structure and setup
library files along with installation and configuration.
I think this might end up being rather tricky, and would appreciate you
detailing this out a bit more, including some expected dates for initial
patch submissions.
We haven't yet decided on how to split gitweb, so I would like to give
a bit more details about this after I take the majority opinion on how
to split gitweb.
quoted
[July 2nd week]
Check for any possible and potential security loopholes or bugs
I appreciate that you are thinking about this, though I'm less sure if
this can be efficiently done as a batch job like this.
I don't think so. Anyway, let's try it. :-)
--
Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
Please ask me if you have any other doubts regarding this proposal.
Thanks
-pavan
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:40
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:
quoted
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).
quoted
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?)
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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:
quoted
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.
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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 [off-list ref] wrote:
quoted
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.
quoted
quoted
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?
quoted
quoted
c) Read modules of the client: (most of this need not be written, just
need to be organised)
1. See the status of repository [git status]
How will you integrate this with the existing 'tree' action?
No, there will be a seperate page for it which executes git status command.
And just passes through its plaintext output? Well, I suppose that could
do for starters.
quoted
--
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
On Mon, Apr 19, 2010 at 5:21 PM, Petr Baudis [off-list ref] wrote:
On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:
quoted
On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
So additional step would be
cp -fvR gitweb/lib /var/www/cgi-bin/ ;# as root
Yes!
quoted
I hope that we could make installing gitweb as easy as
make webscriptdir=/var/www/cgi-bin/ \
gitweb-install
We can try it. :-)
quoted
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.)
quoted
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
Sorry for late reply, I actually skipped this mail.
2010/4/19 Petr Baudis [off-list ref]:
On Mon, Apr 19, 2010 at 12:16:31PM +0530, Pavan Kumar Sunkara wrote:
quoted
On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis [off-list ref] wrote:
quoted
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.
quoted
quoted
quoted
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?
quoted
quoted
quoted
c) Read modules of the client: (most of this need not be written, just
need to be organised)
1. See the status of repository [git status]
How will you integrate this with the existing 'tree' action?
No, there will be a seperate page for it which executes git status command.
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.
quoted
quoted
--
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
On Mon, Apr 19, 2010 at 11:40:33PM +0530, Pavan Kumar Sunkara wrote:
2010/4/19 Petr Baudis [off-list ref]:
quoted
quoted
quoted
quoted
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. :-)
quoted
quoted
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!
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:40
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:40
On Mon, Apr 19, 2010, Petr Baudis wrote:
On Mon, Apr 19, 2010 at 12:43:22PM +0200, Jakub Narebski wrote:
quoted
On Sun, Apr 18, 2010 at 21:56 +0200, Petr Baudis wrote:
quoted
quoted
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]...
quoted
quoted
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"?
quoted
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
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.
From: Petr Baudis <hidden> Date: 2016-06-15 22:48:41
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
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.
quoted
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
From: Christian Couder <hidden> Date: 2016-06-15 22:48:41
On Wednesday 21 April 2010 22:49:02 Pavan Kumar Sunkara wrote:
1.What is the goal of your project?
The project goal is to try and implement write functionalities into gitweb
to go along with it's browsing functionalities. Another goal is to split
gitweb Perl script and reorganize its structure. I would like to split the
gitweb script in such a way that, in the future others will be able to
develop more functionalities for gitweb (let it be 'read' or 'write'
actions) with the help of the framework like structure of the new gitweb.
'read' means browsing through the code and repository
'write' means working on the code and repository.
I will be describing about them detailedly in the later parts of the
proposal.
Perhaps this sentence could be worded like this:
"I will describe in detail the read and write actions in the later part of the
proposal."
2.How would you measure its success or failure?
There are two parameters which would majorly determine the success or
failure of the project.
* Splitting gitweb such that there should be no problem with the
installation of gitweb across cross servers and cross systems.
* Working with new addition to gitweb should be as easy as working with
other git GUIs (git commit tools)
* User friendly graphical interface with smart UI design
3.Describe your project in more detail.
I would like to split the currently 6800 long piece of code in
gitweb.plperl script into small files which will result in better
readability,
maintainability and modifiability. The file structure of the new gitweb is
given below and I will explain the working after it.
(From now on, I would like to call the actions of gitweb as modules of
gitweb)
Perhaps it would be better to state that in the end each action will have its
own Perl module.
Though I agree with Petr that first you should probably just shuffle around all
the utility routines in one module and develop write actions in another module
that uses the first one.
Thanks,
Christian.
On Fri, Apr 23, 2010 at 10:57 AM, Christian Couder
[off-list ref] wrote:
On Wednesday 21 April 2010 22:49:02 Pavan Kumar Sunkara wrote:
quoted
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."
quoted
2.How would you measure its success or failure?
There are two parameters which would majorly determine the success or
failure of the project.
* Splitting gitweb such that there should be no problem with the
installation of gitweb across cross servers and cross systems.
* 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.