Re: [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path"

From: Jeff King <peff@peff.net>
Date: Mar 1, 2009, 10:00 UTC
Message-ID: <20090301100039.GD4146@coredump.intra.peff.net>
In-Reply-To: <7v63itbxe7.fsf@gitster.siamese.dyndns.org>

On Sat, Feb 28, 2009 at 09:54:56PM -0800, Junio C Hamano wrote:

Show 5 quoted lines

> 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