Thread (8 messages) flat view 8 messages, 2 authors, 2016-06-15

Re: Enhancements to git-protocoll

From: Sitaram Chamarty <hidden>
Date: 2016-06-15 22:54:22

On Sun, Jul 29, 2012 at 7:43 PM, Fredrik Gustafsson [off-list ref] wrote:
On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote:
quoted
On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson [off-list ref] wrote:
quoted
Hi,
sometimes git communicates with something that's not git on the other
side (gitolite and github for example).

Sometimes the server wants to communicate directly to the git user.

git isn't really designed for this. gitolite solves this by do user
interaction on STDERR instead. The bad thing about this is that it can
only be one-direction communication, for example error messages.

If git would allow for the user to interact direct with the server, a
lot of cool and and userfriendly features could be developed.

For example:
gitolite has something called wild repos[1]. The management is
cumbersome and if you misspell when you clone a repo you might instead
create a new repo.
For the record, although it cannot do the yes/no part, if you want to
disable auto-creation on a fetch/clone (read operation) it's trivial
to add a "PRE_CREATE" trigger to do that.
Thanks, however I think auto-creation is a great feature for some cases
and I think there can be even more useable functions if we could get
user interaction.
For the record, I don't think I agree.  There's a place to create a
human-conversation, and there's a place not to.

If you want a dialog with the server, there should be *other* commands
that do that, instead of overloading git's own protocol.

Since you mentioned gitolite, consider copying the fork command
(src/commands/fork) and munging the code into an explicit wild repo
create.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help