git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Petr Baudis <pasky@suse.cz>, Jakub Narebski <jnareb@gmail.com>,
	Christian Couder <chriscool@tuxfamily.org>,
	git@vger.kernel.org, Sverre Rabbelier <srabbelier@gmail.com>,
	Shawn O Pearce <spearce@spearce.org>,
	Scott Chacon <schacon@gmail.com>, Sam Vilain <sam@vilain.net>
Subject: Re: GSoC 2010: "Integrated Web Client for git" proposal
Date: Mon, 19 Apr 2010 13:08:26 +0530	[thread overview]
Message-ID: <v2me72faaa81004190038y4aeefa80g9f60bb3b1e795e4b@mail.gmail.com> (raw)
In-Reply-To: <7vfx2rsy6y.fsf@alter.siamese.dyndns.org>

On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Pavan Kumar Sunkara <pavan.sss1991@gmail.com> writes:
>>
>>> Session management reduces the length of URL
>>
>> ... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
>> which is in my opinion a must-have for gitweb.
>
> These self-contained URL are used in bookmarks and e-mails to the mailing
> list.  I think "the length of URL" is a red herring at best, and shortened
> URL that is not self-contained is not an advantage at all.

Yeah, I agree to that.

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

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

What do you say ?

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

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

-pavan

  reply	other threads:[~2010-04-19  7:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-15  4:30 GSoC 2010: "Integrated Web Client for git" proposal Christian Couder
2010-04-18  0:46 ` Jakub Narebski
2010-04-18  0:59   ` Petr Baudis
2010-04-18  1:24     ` Jakub Narebski
2010-04-18  2:12       ` Petr Baudis
2010-04-18  8:52         ` Pavan Kumar Sunkara
2010-04-18 21:22           ` Jakub Narebski
     [not found]             ` <w2pe72faaa81004182334xd6fc56d7o31420ca4af867cc2@mail.gmail.com>
2010-04-19  6:35               ` Pavan Kumar Sunkara
2010-04-19 17:00               ` Jakub Narebski
2010-04-19 17:55                 ` Pavan Kumar Sunkara
2010-04-19 23:14                   ` Jakub Narebski
2010-04-20 12:17                     ` Pavan Kumar Sunkara
2010-04-18 22:31           ` Petr Baudis
2010-04-19  6:46             ` Pavan Kumar Sunkara
2010-04-19  6:50               ` Matthieu Moy
2010-04-19  7:23                 ` Junio C Hamano
2010-04-19  7:38                   ` Pavan Kumar Sunkara [this message]
2010-04-19  9:07                     ` Petr Baudis
2010-04-19 12:27                       ` Matthieu Moy
2010-04-19 12:57                         ` Pavan Kumar Sunkara
2010-04-19 13:14                           ` Matthieu Moy
2010-04-19 11:57               ` Petr Baudis
2010-04-19 18:10                 ` Pavan Kumar Sunkara
2010-04-20 11:47                   ` Petr Baudis
2010-04-18 17:50         ` Jakub Narebski
2010-04-18 19:56           ` Petr Baudis
2010-04-19 10:43             ` Jakub Narebski
2010-04-19 11:51               ` Petr Baudis
2010-04-19 18:03                 ` Pavan Kumar Sunkara
2010-04-20 12:07                   ` Petr Baudis
2010-04-20 18:14                 ` Jakub Narebski
2010-04-21 20:49                   ` Pavan Kumar Sunkara
2010-04-22 20:25                     ` Petr Baudis
2010-04-22 21:15                       ` Junio C Hamano
2010-04-23  7:10                         ` Petr Baudis
2010-04-23  9:44                           ` Junio C Hamano
2010-04-22 21:53                       ` Pavan Kumar Sunkara
2010-04-23  5:27                     ` Christian Couder
2010-04-23  5:42                       ` Pavan Kumar Sunkara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=v2me72faaa81004190038y4aeefa80g9f60bb3b1e795e4b@mail.gmail.com \
    --to=pavan.sss1991@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=pasky@suse.cz \
    --cc=sam@vilain.net \
    --cc=schacon@gmail.com \
    --cc=spearce@spearce.org \
    --cc=srabbelier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).