Re: Enhancements to git-protocoll
- From
Fredrik Gustafsson <iveqy@iveqy.com>
- Date
- Jul 29, 2012, 14:24 UTC
- Message-ID
- <20120729142458.GB16223@paksenarrion.iveqy.com>
- In-Reply-To
- <7vehnvvyta.fsf@alter.siamese.dyndns.org>
On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
Show 33 quoted lines
> Fredrik Gustafsson <iveqy@iveqy.com> 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.
Show 6 quoted lines
> 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@iveqy.com