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

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:40

Matthieu Moy [off-list ref] writes:
Pavan Kumar Sunkara [off-list ref] writes:
quoted
Session management reduces the length of URL
... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
which is in my opinion a must-have for gitweb.
These self-contained URL are used in bookmarks and e-mails to the mailing
list.  I think "the length of URL" is a red herring at best, and shortened
URL that is not self-contained is not an advantage at all.

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

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

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

From: Pavan Kumar Sunkara <hidden>
Date: 2016-06-15 22:48:40

On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano [off-list ref] wrote:
Matthieu Moy [off-list ref] writes:
quoted
Pavan Kumar Sunkara [off-list ref] writes:
quoted
Session management reduces the length of URL
... but OTOH, GET parameters allow painlessly cut-and-paste-able URLs,
which is in my opinion a must-have for gitweb.
These self-contained URL are used in bookmarks and e-mails to the mailing
list.  I think "the length of URL" is a red herring at best, and shortened
URL that is not self-contained is not an advantage at all.
Yeah, I agree to that.
On the other hand, a proposal about giving multiple clients access to
their own individual server-side checkouts (ala "workspace" in DELTA-V)
would require some mechanism to maintain the state on the server end, and
session management would be one ingredient necessary to achieve that.
So, why don't we do like this,
There will be no need of session management when gitweb is installed
in some site like repo.or.cz which needs copy'n'paste URLs
but there will be session management when the write modules are
enabled and when gitweb is installed locally or on intranet (basically
when it is used to work on a repo).

What do you say ?
When I heard that somebody wants to do a "write support" in gitweb, I
naturally thought the proposal was about implementing RFC3253 using git as
a backend.  I think it would be a reasonable thing to do (as opposed to
coming up with an ad-hoc "write support" mechanism that is not compatible
with anybody else), but on the other hand it might be a bit too ambitious
for a one-student summer project.
Sorry but I don't know what it is.
The current average git used are in need of a git client and git-gui
is not doing a good job of it. So, this proposal solves it by
providing client features inside gitweb itself. :-)

-pavan

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

From: Petr Baudis <hidden>
Date: 2016-06-15 22:48:40

On Mon, Apr 19, 2010 at 01:08:26PM +0530, Pavan Kumar Sunkara wrote:
On Mon, Apr 19, 2010 at 12:53 PM, Junio C Hamano [off-list ref] wrote:
quoted
On the other hand, a proposal about giving multiple clients access to
their own individual server-side checkouts (ala "workspace" in DELTA-V)
would require some mechanism to maintain the state on the server end, and
session management would be one ingredient necessary to achieve that.
But what if I will want to give a link to my "workspace" to someone
else? You can embed workspace id in the URL, in fact you would probably
just use it instead of project name completely naturally. I still don't
see any need for sessions.
So, why don't we do like this,
There will be no need of session management when gitweb is installed
in some site like repo.or.cz which needs copy'n'paste URLs
but there will be session management when the write modules are
enabled and when gitweb is installed locally or on intranet (basically
when it is used to work on a repo).

What do you say ?
I think it will be best to discuss session support (and work on
implementing it) when actual features where it is essential will
come up. So far, I'm unable to foresee them, but if we discuss it
later in conjunction with some concrete features, perhaps it will
be clearer.
quoted
When I heard that somebody wants to do a "write support" in gitweb, I
naturally thought the proposal was about implementing RFC3253 using git as
a backend.  I think it would be a reasonable thing to do (as opposed to
coming up with an ad-hoc "write support" mechanism that is not compatible
with anybody else), but on the other hand it might be a bit too ambitious
for a one-student summer project.
I think that would be something entirely different, and IMO even
much less interesting. ;-)

-- 
				Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help