Re: Enhancements to git-protocoll

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Jul 30, 2012, 00:37 UTC
Message-ID: <CAMK1S_hAO0LGHa7e3KY6bT9z+f76Jc6_gCpwYbLqV9WPdgX1Cw@mail.gmail.com>
In-Reply-To: <20120729212627.GA26430@paksenarrion.iveqy.com>

On Mon, Jul 30, 2012 at 2:56 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:

Show 22 quoted lines

> Sorry I missed this thread earlier. I'll drop this if it's not something
> that's wanted.
>
> On Sun, Jul 29, 2012 at 01:51:34PM -0700, Junio C Hamano wrote:
>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>>
>> > 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.
>
> This is exactly the way gitolite works. It's placed between git-server
> and git-client. Does some checks and approves a connection if some
> criterias isn't met. See the example when trying to clone an
> non-existing repo from gitolite. You won't get an git error but a
> gitolite error.
>
> I can understand why my idea is beeing rejected but I can't see why the
> gitolite way should be considered sane. It seems more like an hack to
> me (according to git design principles).
>
> So from a git point of view, why is it sane for passing through STDERR
> but not STDIN and STDOUT?

That is precisely the point. The pack protocol (see Documentation/pack-protocol.txt in the git sources) works with STDIN/STDOUT. Run with GIT_TRACE_PACKET=1 to see some of that info fly past on various git commands.

It explicitly leaves STDERR for the purpose of providing user's extra information, including errors.

Gitolite is merely using that same mechanism.

And I repeat, if you insist on calling what gitolite does an "interaction" (which to me means two-way communication, not a one-way error/warning/diagnostic stream), we do not have enough in common to discuss this any more.