Re: Enhancements to git-protocoll
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- Jul 29, 2012, 14:39 UTC
- Message-ID
- <CAMK1S_iTv3BOV3LEoj83feuO2iQnPqTrOq0wyFC-GrvvJQqWTA@mail.gmail.com>
- In-Reply-To
- <20120729142458.GB16223@paksenarrion.iveqy.com>
On Sun, Jul 29, 2012 at 7:54 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
Show 40 quoted lines
> On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
>> 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.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.
Show 31 quoted lines
> 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@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