This site is an archive; learn more about 8 years of OpenHatch.

[Devel] Git training missions

Jack Grigg me at jackgrigg.com
Fri Apr 1 13:21:38 UTC 2011


Now that I finally have internet access again, I'm just going to drop in 
my two cents:

Running a git:// url is dead simple using git daemon. If we have a base 
folder /git which contains git repositories (whether in that folder or 
subfolders), the following command will serve them up:

git daemon --syslog --enable=receive-pack --export-all --base-path=/git /git

--syslog enables syslog logging.
Add --verbose for verbose logging.

--export-all means that anything looking like a git repository will be 
served, rather than only ones with the "git-daemon-export-ok" file 
(which would be created manually).

--enable=receive-pack enables pushing to a git URL. This has no 
authentication in it, meaning the git repos then have anonymous push 
access as well as anonymous pull. I limit this on my server by requiring 
authentication on anything except GETs on the git.jackgrigg.com vhost in 
Apache, though the actual authentication doesn't work on some setups 
(though I didn't try too hard to get it going because I can just push 
via SSH).

--base-path is the base that is appended onto the path from the git url 
i.e. if we have a git url 
git://openhatch.org/paulproteus/coolmission.git then the daemon will 
serve up /git/paulproteus/coolmission.git/ but without the --base-path 
option, you would need to use the url 
git://openhatch.org/git/paulproteus/coolmission.git

The last /git by itself is the folder containing the repositories to 
serve. No restart is required on adding or removing repositories, so the 
daemon could just be left running.

If you run this as a system process (as I do for git.jackgrigg.com) then 
the --user and --group flags are also useful.

Of course, the http:// method would work just as well =D (this is purely 
for the sake of completeness).

Cheers,
Jack

On 31/03/11 14:32, Mark Freeman wrote:
> Thanks Wil and Asheesh. I believe this will work perfectly.  Like the
> SVN mission, I plan to do the actual commits with the server side
> process and just let them pull the updates.
>
> Wil, I hope to get that up and going in the next couple of days. I'll
> ping you on IRC if I get stuck. Thanks!
>
> On Wed, Mar 30, 2011 at 11:53 PM, Asheesh Laroia<asheesh at asheesh.org>  wrote:
>> On Wed, 30 Mar 2011, Mark Freeman wrote:
>>
>>> Hey everyone! I know I don't tend to make the weekly meetings, so I wanted
>>> to update everyone on where I am with this (and ask some questions).  Right
>>> now, I have almost all of the front end screens built. I also have the code
>>> behind allowing the user to create a personal git repo, and resetting the
>>> repo, completed.  I'm currently in the process if writing the methods to
>>> parse the patch file and verify the user correctly made the changes.
>> That is super exciting, Mark! Once you've been through it, maybe you can
>> also help us fix up the "How to write a mission" documentation, because
>> you've been through it. It's a crime that the documentation there isn't
>> perfect, because we really could use good missions.
>>
>>> I have a question!  Once I know this, I'm hoping to get this wrapped up in
>>> the next couple of weeks.  Currently the repo is created in
>>> mysite/missions-userdata/git/<username>  in exactly the same way the svn
>>> mission is.  Does anyone know git well enough to know how to serve this to
>>> the user so it can be accessed using a standard "git clone
>>> git://openhatch.org/timewasted git_missions"?
>> Will makes a really good point about just using having Apache (on the
>> deployment) serve out the git repositories over HTTP. I'd be okay with that.
>>
>> It'll be easy for us to do, too. We'll just add a config line to the server
>> like:
>>
>> Alias /git-missions/ /path/to/mysite/missions-userdata/git/
>>
>> And Apache will serve it out. That's good enough, so long as it's okay that
>> people's repositories are world-readable. (If your design is okay with that,
>> then that's good. If not we should try harder to work something else out.)
>>
>> In the test suite, you can tell git to "git clone" against the local
>> filesystem, and that should work okay. (The svn mission does something
>> similar.)
>>
>> Do you think that'll work out for you?
>>
>> (-:,
>>
>> -- Asheesh.
>>
>> --
>> Your talents will be recognized and suitably rewarded.
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.openhatch.org
>> http://lists.openhatch.org/mailman/listinfo/devel
>>
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>


More information about the Devel mailing list