From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:54:22
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.
This could have been avoided with a simply:
"Do you want to create a new repo[Yn]"
To fix this, git protocol should have a command for printing input to
STDOUT and accepting input on STDIN which should be sent to the server.
And a command to switch back to orginal of course.
The server could then switch to user interaction, do that and then
switch back to normal operation.
Before eventually starting to implement this, I would know your
opinions. This feature would be wortless if it's not in the official git.
[1] http://sitaramc.github.com/gitolite/wild.html
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson [off-list ref] wrote:
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.
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:54:22
On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote:
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.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
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.
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:54:22
On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote:
quoted
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.
I appriciate that you clearified you oppinion. Please excuse me if it
sounded as I in any way speaked for gitolite. I use gitolite as an
example becuase the target application in this case is unknown to most
people (think gitolite with db-backend for user permissions).
It's a valid design oppinion to not mix git protocoll with anything
else. But gitolite already does that. Gitolite already have user
interaction mixed with git interaction. Do you say to me that gitolite
is broken and should not do user interaction over git-commands? Then why
does wild repos exists and why does gitolite error messages exists?
We're already down that road, why not do it better?
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson [off-list ref] wrote:
On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote:
quoted
quoted
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.
I appriciate that you clearified you oppinion. Please excuse me if it
sounded as I in any way speaked for gitolite. I use gitolite as an
example becuase the target application in this case is unknown to most
people (think gitolite with db-backend for user permissions).
It's a valid design oppinion to not mix git protocoll with anything
else. But gitolite already does that. Gitolite already have user
interaction mixed with git interaction. Do you say to me that gitolite
is broken and should not do user interaction over git-commands? Then why
does wild repos exists and why does gitolite error messages exists?
We're already down that road, why not do it better?
I think you misunderstood how gitolite works. Gitolite does not have
*any* user interaction other than sending some extra messages back via
STDERR if you're using a normal git client to do normal git operations
(clone/fetch/ls-remote).
Such messages are *no different* from something that an update or
pre-receive hook might send back even on a normal (no gitolite) git
server.
The only time that gitolite might have any user *interaction* is when
using "gitolite commands". These do not run git at all (neither on
the client nor on the server), and in fact merely provide a convenient
way to allow users to run a controlled set of specific *shell*
commands.
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:54:22
On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote:
I think you misunderstood how gitolite works. Gitolite does not have
*any* user interaction other than sending some extra messages back via
STDERR if you're using a normal git client to do normal git operations
(clone/fetch/ls-remote).
As you say, gitolite has userinteraction, and its not even standard to
git error messages. Try cloning a repo that doesn't exists via gitolite
and a regular ssh connection:
[iveqy@paksenarrion git]$ git clone ssh://gitolite@localhost/testing2
Cloning into testing2...
FATAL: R any testing2 id_rsa DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly
[iveqy@paksenarrion git]$ git clone ssh://iveqy@localhost/testing2
Cloning into testing...
fatal: '/testing2' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Such messages are *no different* from something that an update or
pre-receive hook might send back even on a normal (no gitolite) git
server.
As I showed above the "non-existing" repo is a case when it's different.
But you have a good point in hooks, of course a hook also should be able
to have two way user interaction.
The only time that gitolite might have any user *interaction* is when
using "gitolite commands". These do not run git at all (neither on
the client nor on the server), and in fact merely provide a convenient
way to allow users to run a controlled set of specific *shell*
commands.
I do understand how gitolite works. However this is off-topic to my
original question. I also do not have an oppinion on how gitolite
should work, I simply don't care. Gitolite is an widely acceptet git
tool, I see improvement opportunities in git to allow an other
program to utilize two-way user interaction all the time, this will not
effect gitolite at all.
So in my point of view, it's up to Junio if I shall continue explore this
path and maybe find a way of doing this in git, "the right way". Or if
this is something unwanted and gitolite and alike programs should
continue with STDERR "hacks".
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
On Sun, Jul 29, 2012 at 9:11 PM, Fredrik Gustafsson [off-list ref] wrote:
On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote:
quoted
I think you misunderstood how gitolite works. Gitolite does not have
*any* user interaction other than sending some extra messages back via
STDERR if you're using a normal git client to do normal git operations
(clone/fetch/ls-remote).
As you say, gitolite has userinteraction, and its not even standard to
I think we differ on the meaning of the word "interaction".