On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
> Fredrik Gustafsson <iveqy@xxxxxxxxx> writes:
>
> > Sometimes the server wants to communicate directly to the git user.
> > ...
> > 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]"
>
> I do not think the automatic repository creation done by gitolite is
> a good use case or example for whatever you seem to be advocating.
>
> IIUC, the auto-creation in gitolite-shell::main() is done way before
> gitolite-shell (which is used as a login shell for incoming ssh
> sessions) creates a new git repository, goes into it and spawns the
> git-receive-pack command. It all happens outside Git.
>
> # auto-create?
> if ( repo_missing($repo) and access( $repo, $user, '^C', 'any' ) !~ /DENIED/ ) {
> require Gitolite::Conf::Store;
> Gitolite::Conf::Store->import;
> new_wild_repo( $repo, $user, $aa );
> gl_log( 'create', $repo, $user, $aa );
> }
>
> The "access()" we see here is not the Perl builtin access(), but is
> a function defined in src/lib/Gitolite/Conf/Load.pm; that would be
> the place to allow the incoming ssh session to talk back to the end
> user, but at that point there is no Git processing on the server
> end.
That's a feature. It means that the impact on git would be rather small,
we don't have to involve server-side git at all. The problem so solve is
how to get client-side git to pass through STDIN and STDOUT (just as is
done with STDERR right now). I see this as a gitolite <-> client-git
interaction case. No server-git should be involved.
All the use casese I can imagine will be done before (or after)
serverside git is executed.
> While I am not fundamentally opposed to adding yet another sideband
> channel to the git protocol, I do not think adding user interaction
> at random places in the protocol exchange is a viable or useful
> approach to implement an enhanced server that works with both
> enhanced and vanilla clients (and the same is true for enhanced
> client that works with both enhanced and vanilla server).
Do we mean the same thing with "git protocol"? I specify the protocol as
everything that happens between the server and the client. Are the
connection divided into multiple protocoll after eachother? (would it be
possible to execute git-user-interaction-protocoll first and the
git-protocoll and then git-user-interaction-protocoll again?).
The vanilla case would be easy to solve if the protocol has git version
in its handshake. The STDERR approach is already used and working. A
vanilla client would have the same functionality as today and en
enhanced client will have enhanced functionality.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html