On Sun, Jul 29, 2012 at 7:54 PM, Fredrik Gustafsson <iv...@iveqy.com> wrote:
> On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
>> Fredrik Gustafsson <iv...@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.
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.
>
>> 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: iv...@iveqy.com
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
