git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fredrik Gustafsson <iveqy@iveqy.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>,
	gitster@pobox.com, git@vger.kernel.org
Subject: Re: Enhancements to git-protocoll
Date: Sun, 29 Jul 2012 17:41:24 +0200	[thread overview]
Message-ID: <20120729154124.GA19201@paksenarrion.iveqy.com> (raw)
In-Reply-To: <CAMK1S_hHBB9BViH=CFuJNgMJzMtzhE0mGc7ryFaDWNxOoH2Pgg@mail.gmail.com>

On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote:
> I think you misunderstood how gitolite works.  Gitolite does not have
> *any* user interaction other than sending some extra messages back via
> STDERR if you're using a normal git client to do normal git operations
> (clone/fetch/ls-remote).

As you say, gitolite has userinteraction, and its not even standard to
git error messages. Try cloning a repo that doesn't exists via gitolite
and a regular ssh connection:

[iveqy@paksenarrion git]$ git clone ssh://gitolite@localhost/testing2
Cloning into testing2...
FATAL: R any testing2 id_rsa DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly
[iveqy@paksenarrion git]$ git clone ssh://iveqy@localhost/testing2
Cloning into testing...
fatal: '/testing2' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

> Such messages are *no different* from something that an update or
> pre-receive hook might send back even on a normal (no gitolite) git
> server.

As I showed above the "non-existing" repo is a case when it's different.
But you have a good point in hooks, of course a hook also should be able
to have two way user interaction.

> The only time that gitolite might have any user *interaction* is when
> using "gitolite commands".  These do not run git at all (neither on
> the client nor on the server), and in fact merely provide a convenient
> way to allow users to run a controlled set of specific *shell*
> commands.

I do understand how gitolite works. However this is off-topic to my
original question. I also do not have an oppinion on how gitolite
should work, I simply don't care. Gitolite is an widely acceptet git
tool, I see improvement opportunities in git to allow an other
program to utilize two-way user interaction all the time, this will not
effect gitolite at all.

So in my point of view, it's up to Junio if I shall continue explore this
path and maybe find a way of doing this in git, "the right way". Or if
this is something unwanted and gitolite and alike programs should
continue with STDERR "hacks".

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

  reply	other threads:[~2012-07-29 15:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-28 21:41 Enhancements to git-protocoll Fredrik Gustafsson
2012-07-29  6:58 ` Junio C Hamano
2012-07-29 14:24   ` Fredrik Gustafsson
2012-07-29 14:39     ` Sitaram Chamarty
2012-07-29 20:51       ` Junio C Hamano
2012-07-29 21:26         ` Fredrik Gustafsson
2012-07-30  0:37           ` Sitaram Chamarty
2012-07-29 21:38         ` Junio C Hamano
2012-07-30  1:04           ` Sitaram Chamarty
2012-07-30  1:21             ` Shawn Pearce
2012-07-30  1:33               ` Sitaram Chamarty
2012-07-30  2:38               ` Junio C Hamano
2012-07-30  5:20                 ` Shawn Pearce
2012-07-30  6:28                   ` Junio C Hamano
2012-07-30  8:12                     ` Sitaram Chamarty
2012-07-30  8:31                     ` Sitaram Chamarty
2012-07-30  1:28             ` Junio C Hamano
2012-07-30  1:45               ` Sitaram Chamarty
2012-07-29 10:37 ` Sitaram Chamarty
2012-07-29 14:13   ` Fredrik Gustafsson
2012-07-29 14:25     ` Sitaram Chamarty
2012-07-29 15:05       ` Fredrik Gustafsson
2012-07-29 15:15         ` Sitaram Chamarty
2012-07-29 15:41           ` Fredrik Gustafsson [this message]
2012-07-29 18:22             ` Sitaram Chamarty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120729154124.GA19201@paksenarrion.iveqy.com \
    --to=iveqy@iveqy.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sitaramc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).