From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path"
Date: Sun, 1 Mar 2009 05:00:39 -0500 [thread overview]
Message-ID: <20090301100039.GD4146@coredump.intra.peff.net> (raw)
In-Reply-To: <7v63itbxe7.fsf@gitster.siamese.dyndns.org>
On Sat, Feb 28, 2009 at 09:54:56PM -0800, Junio C Hamano wrote:
> One issue I did not describe in the message was to what extent we would
> want to allow operations other than the creating of a new repository
> itself.
>
> "Other than the creation" includes things like these:
Hmph. I am not too excited by this list. What is the advantage of doing
them over the git protocol versus some out-of-band method?
It seems to me there are two main cases for dealing with a remote in
this way:
1. You have shell access and a uid on the remote, but it is
inconvenient to ssh across, find the repo (which may already be
known locally by remote.*.url config), and then execute some
commands.
In this scenario, there really are no security concerns; you could
have logged in and done all of this anyway. So it seems like a more
natural fit would be a _client_ program that figures out what shell
snippet you want to execute, connects to the remote, and does it.
2. Your access on the remote is very restricted, you may not have your
own uid, and hooks may be enforcing arbitrary security policy.
In this case, even something as simple as chgrp seems like it could
be a problem, depending on the remote's setup (e.g., because all
users connect as one uid, but group permissions are somehow
meaningful to the system; this implies that connecting users should
not be able to arbitrarily chgrp their repos, even if chgrp itself
allows it).
Furthermore, in the case of many providers (e.g., github,
repo.or.cz), there is already a separate out-of-band interface for
doing "meta" stuff, like managing user accounts and repos. Isn't it
more natural for them to integrate these features with their
existing interfaces?
But let's say that there really is some value in setting up this
channel (because we want a uniform way of doing these things so we can
add more automated tool support from the client side). Then I think it
makes sense to look at what the people in (2) above are doing already.
That is, what sorts of things can you already do (and not do) in
github's or repo.or.cz's interface? On top of that, it probably makes
sense to ask them if they are interested in such a feature, as they
would be primary users. And if they are, what do they want out of it?
-Peff
next prev parent reply other threads:[~2009-03-01 10:02 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-01 0:03 [PATCH 1/4] Refactor list of environment variables to be sanitized Junio C Hamano
2009-03-01 0:03 ` [PATCH 2/4] git-init: inject some sanity to the option parser Junio C Hamano
2009-03-01 0:03 ` [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path" Junio C Hamano
2009-03-01 0:03 ` [PATCH 4/4] " Junio C Hamano
2009-03-01 3:16 ` [PATCH 3/4] Add init-serve, the remote side of " Jeff King
2009-03-01 5:54 ` Junio C Hamano
2009-03-01 10:00 ` Jeff King [this message]
2009-03-01 17:04 ` Shawn O. Pearce
2009-03-03 6:50 ` Subject: [PATCH] Push to create Junio C Hamano
2009-03-03 7:09 ` Jay Soffian
2009-03-03 7:09 ` Jeff King
2009-03-03 7:37 ` Jay Soffian
2009-03-03 7:39 ` Jay Soffian
2009-03-03 7:56 ` Junio C Hamano
2009-03-03 8:02 ` Jay Soffian
2009-03-03 8:04 ` Junio C Hamano
2009-03-03 8:04 ` Junio C Hamano
2009-03-03 8:16 ` Jay Soffian
2009-03-03 8:23 ` Jeff King
2009-03-03 19:57 ` Jay Soffian
2009-03-04 5:42 ` Jeff King
2009-03-04 6:35 ` Junio C Hamano
2009-03-04 13:06 ` Jay Soffian
2009-03-03 7:55 ` Junio C Hamano
2009-03-03 8:06 ` Jeff King
2009-03-03 8:22 ` Junio C Hamano
2009-03-03 8:27 ` Jeff King
2009-03-03 8:30 ` Junio C Hamano
2009-03-03 8:41 ` Jay Soffian
2009-03-03 9:23 ` Theodore Tso
2009-03-03 10:39 ` Johannes Schindelin
2009-03-04 17:58 ` Theodore Tso
2009-03-06 1:37 ` Miles Bader
2009-03-03 18:41 ` Shawn O. Pearce
2009-03-04 8:32 ` [RFC/PATCH 1/2] improve missing repository error message Jeff King
2009-03-04 9:19 ` Matthieu Moy
2009-03-04 10:35 ` Jeff King
2009-03-04 18:57 ` Shawn O. Pearce
2009-03-05 10:36 ` Jeff King
2009-03-04 8:42 ` [RFC/PATCH 2/2] make remote hangup warnings more friendly Jeff King
2009-03-04 19:04 ` Shawn O. Pearce
2009-03-05 10:45 ` Jeff King
2009-03-03 21:08 ` Subject: [PATCH] Push to create Daniel Barkalow
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=20090301100039.GD4146@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).