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

[Pavan Kumar Sunkara <pavan.sss1991@gmail.com>]

Sorry for late reply, I actually skipped this mail.

2010/4/19 Petr Baudis <pasky@suse.cz>:
> On Mon, Apr 19, 2010 at 12:16:31PM +0530, Pavan Kumar Sunkara wrote:
>> On Mon, Apr 19, 2010 at 4:01 AM, Petr Baudis <pasky@suse.cz> wrote:
>> > Frankly, I'm not very excited from this. First, I recommend that you
>> > completely separate splitting of gitweb to smaller pieces (without any
>> > major conceptual changes) both in the proposal and in actual
>> > submissions.
>> >
>> > Second, you should justify the introduction of session management and
>> > templating. What is the point and why is it neccessary for your project
>> > goals?
>> >
>>
>> Session management reduces the length of URL and templating reduces
>> the amount of HTML in the actual code.
>
> ...which is bad?
>
> I don't see the value in session management; making the URL contain less
> information is not _good_, it is _very_ _bad_, since you can't use the
> Uniform Resource Locator to locate resources anymore.
>
> Introduction of templating would mean huge changes (not only addition of
> the templater) for seemingly no warranted reason. I mean, if we were to
> start writing gitweb from scratch, perhaps a templater engine *might*
> warrant some consideration, but I don't see any itch we want to scratch
> by introducing templating now. And no connectoin with the project at
> hand.
>
>> >> b) Write modules of the client:
>> >>  15. Search for a part of code [git grep]
>> >
>> > This is already supported by gitweb. And it's not a "write" operation.
>> > ;-)
>>
>> I wrote it here because I would like to integrate it with content
>> history browser functionality later.

If you remember, there is a gsoc idea named "Content History Browser"
in ideas wiki page that is listed by you. It's about starting giddy
from scratch to use pickaxe interface to see the history of a specific
content. I would like to integrate this with that pickaxe interface.

> I don't understand, can you elaborate?
>
>> >> c) Read modules of the client: (most of this need not be written, just
>> >> need to be organised)
>> >>
>> >>   1. See the status of repository [git status]
>> >
>> > How will you integrate this with the existing 'tree' action?
>>
>> No, there will be a seperate page for it which executes git status command.
>
> And just passes through its plaintext output? Well, I suppose that could
> do for starters.

No. It won't be just plain text. Every line will have links beside it
to either stage or unstage or add or ignore or see diff for that file.

>> > --
>> >                                Petr "Pasky" Baudis
>> > http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
>> >
>>
>> Please ask me if you have any other doubts regarding this proposal.
>
> Could you clarify your attitude to the support for mode without checked
> out working copy, using just the index, that we are discussing with
> Jakub and I already mentioned to you in the past?

Yes, I remember it. TO be frank, I don't know the git commands to
implement this. So, If you can explain it to me more detailedly, Then
I can implement it for sure.

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

Thanks
-pavan