git repository mirrors?

git repository mirrors?

[Jim Meyering]

Hi,

This is mostly a heads-up, I suppose.

I've begun using the device-mapper and lvm2 repositories recently and find
that using them through a git mirror is more effective.  So I've set up
personal cvs-to-git mirrors that are updated incrementally (efficiently).
I plan to publish these read-only repositories on git.et.redhat.com
very soon.  That's relatively easy for me, because there is already a
tried git server configured and running there.  And it's easy to keep
them up to date.

However, if sourceware has such infrastructure already in place (or
will soon), it'd make more sense to do it on the system hosting the
"upstream" repository.

Jim

Re: git repository mirrors?

[Frank Ch. Eigler]

Hi -

> [...]  However, if sourceware has such infrastructure already in
> place (or will soon), it'd make more sense to do it on the system
> hosting the "upstream" repository.

There is not git server daemon running, but some version of the git
suite is installed.  

If you had shell access, you could in theory put a shared git repo
somewhere under a project directory (/sourceware/projects/lvm2-home or
/sourceware/www/sourceware/htdocs/lvm2) and export at least read-only
http access to it.

cgf, would it be hard to make your restricted-shell ssh wrapper to  
also accept git?

- FChE

Re: git repository mirrors?

[Jim Meyering]

"Frank Ch. Eigler" <fche@redhat.com> wrote:
>> [...]  However, if sourceware has such infrastructure already in
>> place (or will soon), it'd make more sense to do it on the system
>> hosting the "upstream" repository.
>
> There is not git server daemon running, but some version of the git
> suite is installed.
>
> If you had shell access, you could in theory put a shared git repo
> somewhere under a project directory (/sourceware/projects/lvm2-home or
> /sourceware/www/sourceware/htdocs/lvm2) and export at least read-only
> http access to it.
>
> cgf, would it be hard to make your restricted-shell ssh wrapper to
> also accept git?

Thanks, but the http-hamstrung git isn't worth it: not nearly
as efficient, and rarely used, so probably not as robust.
IMHO, the only worthwhile way to allow read-only git access
is to open the git port, 9418.

If this is a hassle for you guys, don't worry.
I think I have all the pieces in place on et.redhat.com.

Re: git repository mirrors?

[Jim Meyering]

"Frank Ch. Eigler" <fche@redhat.com> wrote:
>> [...]  However, if sourceware has such infrastructure already in
>> place (or will soon), it'd make more sense to do it on the system
>> hosting the "upstream" repository.
>
> There is not git server daemon running, but some version of the git
> suite is installed.
>
> If you had shell access, you could in theory put a shared git repo
> somewhere under a project directory (/sourceware/projects/lvm2-home or
> /sourceware/www/sourceware/htdocs/lvm2) and export at least read-only
> http access to it.
>
> cgf, would it be hard to make your restricted-shell ssh wrapper to
> also accept git?

FYI, I've set things up on et.redhat.com.  Currently it does
an rsync (and then maybe git-cvsimport/git-push) for each cvs
repository every 15 minutes:

    http://git.et.redhat.com/?p=lvm2.git
    http://git.et.redhat.com/?p=device-mapper.git

You can get a copy of either repository like this:
(this uses the efficient "git://" protocol, and is sort of
analogous to CVS pserver.  i.e. anonymous, for read-only access)

    git clone git://et.redhat.com/lvm2
    git clone git://et.redhat.com/device-mapper

Ideally (both from reliability and user-expectations perspective), the
git repo would be on sourceware along with the original CVS one.
I'd be happy to help out if you don't mind opening the git port
and hosting the gitweb.cgi that's used for the http: URLs above.
Everything is pretty well automated already, so setting it up in the
"right" place wouldn't involve much more work.

Please let me know one way or another.  If there's a good chance of
setting up a git server on sourceware.org, I won't announce the above.

Regards,

Jim