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.


 
--

[ message continues ]

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

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

Yes. Though it is probably supposed to be real Git frontend with Git

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

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

[ message continues ]

Hmmm... doesn't look so easy.  What to do about simultaneous access

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

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

[ message continues ]

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

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

This already occured to me, yes. It's tempting to have this as the

Yes, but not things like href(), git_header_html() and other absolutely

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

[ message continues ]

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

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

This paragraph is in my opinion a bit unnecessary.  It would be useful

What are those "write functionalities"?  There are many different 
features that can be described as "write functionalities": what exactly 

You probably meant here "into gitweb to go along with its browsing

Grammar.  "Another goal is to split gitweb Perl script and reorganize 

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,


That is a good idea: the requirement that installing gitweb should
be easy after splitting it, and it should work for many ...
[ message continues ]

I don't know perl but learning it an d becoming proficient in it won't
be a matter for me. I believe I am a fast learner and I am a computer
science student in the top university of India. I learnt python in an
hour and became proficient in it by a week. So learning perl won't be


It's an error with my grammar. I actually mean to concentrate on "edit" part.







Yes, exactly. I think you haven't read the whole proposal before

I would like to add a small 50 lines code for templater class which
does string substitution and embed the module output into tpl file.
This method reduces the subroutines like git_header_html etc.. A small
example of templater class can be found at
http://matetelki.com/blog/?p=71. It isn't exactly the same i use but


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



I mean wouldn't using session be good thing to add. It doesn't need to


The basic library files like errorhandlers, session manager,


Let us say if there are multiple repositories in multiple paths,
wouldn't it be good to add a single project. This option will be





It can lead to merge conflicts but what I mean is you cannot solve it



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


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



Yes. I will not be doing it in GSoC and it won't be a part of gitweb,

I mean, I will be providing an web API wrapper for gitweb which can be
used by other web developers to store any information they get into a
git repository form and can use it to see the changes they made to the


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

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

[ message continues ]

I can agree that you would be able to learn Perl in a week.  I do not
think however that you can become proficient in Perl (and neither in any
other non-trivial programming language) in such short time.  The question

Errr... my comment was about technical language / jargon used...

As to "I would like to take the majority opinion on how to split gitweb":
in my opinion you would need to have your own idea on how to split gitweb
yourself, to avoid possibility of wasting time on bikeshedding[1].  
Of course this would be based on discussion here on git mailing list.
All of this assuming that this project would get accepted.


Yes, I found it in later parts of proposal, but don't you think that
this goal of this project should be stated upfront, so that one can

I have not.  I got it from discussion in parallel subthread, so I asked
for clarification.  But I should have to read the whole proposal, or
know extra information to get what you were trying to say here.  

Currently gitweb does not use any templating engine.  Adding it would
be additional work, in my opinion not really necesary for the goals of
project (splitting gitweb is more on less needed to be able to add
large new feature, such as committool / "write" bit).  I don't think
there is enough time to (optionally) code and add templating to gitweb.

Additionally, while adding very simple templating class wouldn't be
to much violation of programming guidelines (and for example both
Mojolicius and Dancer web micro-frameworks include their own simple
templating system), I am afraid that simple string / variable 
substitution would be not enough for gitweb: loops and conditionals
would also be required.  Also we would probably want for templating
system to automatically escape (when requested).  So templating engine
grows... and then it would really be better to just use one of existing
templating modules from CPAN (http://search.cpan.org), or add adapter
to one of templating system from CPAN (like Catalyst web ...
[ message continues ]

I can learn perl in 3 hours. Becoming proficient in perl is just
knowing about all the majorly used inbuilt functions and libraries.
Coming to the concepts of programming, I already know a lot about it
along with Data structures and algortihms. So you need not doubt me on

Sorry about that.

I have already given my idea in the proposal. I would like to hear
your opinions and implement the majority opinion if my  idea is full

I thought it should be described later in the "Describe your project



You are half correct.
lib/ contains modules *required* by gitweb
modules/ contains actions *performed* in gitweb like commitlog,
snapshot etc.. (write actions too)


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

How about like this ?
We will have a static file with list of projects. All the repositories
in scan path will be added to this list. Then we will also have an
option to add an existing repository which can be done when the user




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

-pavan
--

[ message continues ]

You can (probably) learn Perl *syntax* in 3 hours.  You perhaps can
learn to start to write clean, idiomatic Perl within a week, provided
that you find good books (like "Higher-Order Perl", which can be found
at http://hop.perl.plover.com/book/, or other Perl books from O'Reilly).
Be proficient in Perl in that short time?  I don't think so.

I guess that you can learn enough Perl for this project, but I'd really

Nevetheless it is a place to describe *specific* goal of project here,
in one to two sentences.  No marketing buzzwords here :-PPP
 

I don't understand why actions are not to be in lib/, like e.g. SVN::Web
(http://p3rl.org/SVN::Web) has SVN::Web::Blame module for 'blame' action?
Although I am not sure if SVN::Web is a good example of coding practices

O.K. that is a good idea: make gitweb scan for repositories, and present
user with the list of them to add to static list of visible projects 

I'm sorry, we seem to have a bit of misunderstanding here.  What I meant
that this should be in the "optional" part of GSoC project, so it would
be worked on during GSoC only after everything else is done.  Because the
scope of this project is quite wide, I though it unlikely to have time
left at the end of GSoC after finishing all other more important features.

I did not mean to say that you would be unlikely to contribute after GSoC
finishes.
 
-- 
Jakub Narebski
Poland
--

[ message continues ]

It's your choice. All I can say is learning perl won't be a

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


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

Thanks
-pavan
--

[ message continues ]

Thanks for work on the proposal!


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


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

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

This is already supported by gitweb. And it's not a "write" operation.




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


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

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

[ message continues ]

Yes, I promise that I will try my best to submit patches early and try

Session management reduces the length of URL and templating reduces

[8] includes creating and deleting branches along with listing and
switching where as [11] includes just switching and also allows to

I wrote it here because I would like to integrate it with content





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


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

Thanks
-pavan
--

[ message continues ]

... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
which is in my opinion a must-have for gitweb.

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

[ message continues ]

These self-contained URL are used in bookmarks and e-mails to the mailing
list.  I think "the length of URL" is a red herring at best, and shortened
URL that is not self-contained is not an advantage at all.

On the other hand, a proposal about giving multiple clients access to
their own individual server-side checkouts (ala "workspace" in DELTA-V)
would require some mechanism to maintain the state on the server end, and
session management would be one ingredient necessary to achieve that.

When I heard that somebody wants to do a "write support" in gitweb, I
naturally thought the proposal was about implementing RFC3253 using git as
a backend.  I think it would be a reasonable thing to do (as opposed to
coming up with an ad-hoc "write support" mechanism that is not compatible
with anybody else), but on the other hand it might be a bit too ambitious
for a one-student summer project.
--

[ message continues ]

So, why don't we do like this,
There will be no need of session management when gitweb is installed
in some site like repo.or.cz which needs copy'n'paste URLs
but there will be session management when the write modules are
enabled and when gitweb is installed locally or on intranet (basically
when it is used to work on a repo).


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

-pavan
--

[ message continues ]

But what if I will want to give a link to my "workspace" to someone
else? You can embed workspace id in the URL, in fact you would probably
just use it instead of project name completely naturally. I still don't

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

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

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

[ message continues ]

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

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

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

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

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

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

[ message continues ]

All of us are supporting using GET parameters rather than sessions for
project name and others which is fine for me as the reasons are valid.
But I would like to develop sessions manager incase they want to use
authentication support.

What do you say ?

-pavan
--

[ message continues ]

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

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

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

[ message continues ]

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


And just passes through its plaintext output? Well, I suppose that could

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

[ message continues ]

Sorry for late reply, I actually skipped this mail.


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

No. It won't be just plain text. Every line will have links beside it

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

Thanks
-pavan
--

[ message continues ]

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

[ message continues ]

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

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
                                              ^^^^^^^^^^-- ???
But what?

Yes, it is not as elegant as "require", and you have to catch errors


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

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


Oops, sorry. I meant that it should be really only last result if we try

I don't really think things can get *any* more complicated than "also

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

[ message continues ]

For that you would need editing file / editing contents action, but

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

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; 

Well, I would perhaps start simply with 

  gitweb.perl
  ...
[ message continues ]

Yes. Not a whole lot of effort, seems to me. A downside is that you

I think even just going through a temporary file is fine for initial


Ideally, yes, but that's not directly tied to the splitting effort.

That sounds like the best way. :)

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

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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"


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

[ message continues ]

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

Hi!


  (I have reservations to this particular structure and naming, but I


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


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

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

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

[ message continues ]

What do you mean by "without working copy"?  Is the proposal about having
a working copy _per_ client on the server side, and the file editor and
goodies listed in the "Wrote modules" list operate on these files?

Perhaps you meant to say "without working copy on the client side", and if
that is the case I think we are on the same wavelength.  That is exactly
why I earlier said that I imagine that the "Gitweb client write support"
would be based on something more standard like DeltaV, instead of rolling
a custom hack that is not compatible with anybody else.
--

[ message continues ]

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

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

  DeltaV?

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

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

[ message continues ]

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

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

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

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

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

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

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

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

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

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

[Footnote]

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

[ message continues ]

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

[ message continues ]

Perhaps this sentence could be worded like this:

"I will describe in detail the read and write actions in the later part of the 

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.

--

[ message continues ]

On Fri, Apr 23, 2010 at 10:57 AM, Christian Couder


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

Thanks
-pavan
--

[ message continues ]