[sslh] git repo?

[Jason Cooper]

On Wed, Jul 10, 2013 at 03:05:59PM +0200, Yves Rutschle wrote:
> On Tue, Jul 09, 2013 at 02:30:46PM -0400, Jason Cooper wrote:
> > Darn, I was hoping to just untar, cleanup, commit, repeat ;-)
> 
> Actually, that's probably what I'll do -- after checking it
> out (so to speak), my SVN's history is of no value to
> anyone, not even history.
> 
> > I don't like imposing my way on other developers, particularly with
> > their own projects.  But if you've been considering making the jump, I
> > can say it would make patch submission a *lot* easier. <nudge, nudge>
> > 
> > If that 'probably' turns out to be a 'yes', just yell.  I do quite a bit
> > with git.  Yes, that rhymes, and no it wasn't intentional.  :)
> 
> I only do a lil bit with git, but yesterday I wished I could
> stash, so I'll fire up bash and enjoy git's hash (which is
> sha). Ahem. :)
> 
> More to the point, question to the experienced user: is a
> public HTTP repository OK, or is it much better to have a
> git daemon?

I personally have my stuff at git.infradead.org (users/jcooper) and I've
used David's setup as a template for an in-house git server as well.

Generally, you have two scenarios, users and owners.  Users typically
need to browse (http) and clone (git).  Owners need to create/delete
(ssh), push (ssh), and occasionally pull (git).

I suppose you can clone/pull via https, I've just never tried it.  I
think that is the default now for github.

> I strongly tend towards HTTP to avoid a new
> service (and then I'd need to add git support to sslh...)
> but I'm not sure that's not overly restrictive.

git-receive-pack and git-send-pack are the strings sent over the wire
for git transfers, regardless of exterior protocol (git, ssh, https).
See my code for doing automated, passwordless ssh git transfers using
single purpose keys [1].  Warning:  It's still under review, so I
wouldn't trust it in places where security is needed.

thx,

Jason.

[1] http://git.infradead.org/users/jcooper/secsh.git/tree