Re: Enhancements to git-protocoll

On Sun, Jul 29, 2012 at 7:54 PM, Fredrik Gustafsson [off-list ref] wrote:

On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:

quoted

Fredrik Gustafsson [off-list ref] writes:

quoted

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.

Uggh, no.  Client-git should only talk to server-git.  It shouldn't be
talking first to some *other* program (in this case gitolite), and
then to to server-git.  That doesn't sound sane to me.

You should wrap this whole thing around something else that does it in
3 steps.  Check, create if needed, then the actual git command you
intend to run.  All this should be local to your environment, not
rolled into git; it's far too specific to be rolled into git itself,
if you ask me.

All the use casese I can imagine will be done before (or after)
serverside git is executed.

quoted

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sitaram