More and more development tools are supporting git repository URLs as a way of pointing to code or data. That’s convenient if you’re working with a mature, third-party repository that’s already hosted, but it means that sometimes you just need a quick way to serve a repo over a web interface for experimental work.
This takes a repo in
path/to/repo and serves it from a new
repo-http. I’ve tested it on GNU/Linux, but
it should even work on Windows if you use
rename instead of
The Python command starts a web server that stays running in the foreground, dumping request logs to the console. Keep it running and use another terminal for other work. It should now be possible to access your repo from another machine over port 8000:
If you update the original repository on the same machine, you can push the changes to the serving copy:
(Make sure you’re in the original repository. I.e., do
path/to/repo if you have to.)
Limitations and Alternatives
This is seriously not production-worthy. There’s no access control, there’s no encryption, you can’t push to the repo through it, and I wouldn’t trust it for heavy traffic or long-term robustness. It’s purely for quick experiments with certains tools that demand a URL to an online git repo, and when the alternatives below aren’t suitable.
On a local machine, many tools that support git (including git itself) also support plain paths (or at least
SSH works best most of the time for ad hoc git access over a network. (E.g.,
ssh://firstname.lastname@example.org/path/to/repo) Git can push over ssh, and of course
you get encryption and simple access control. Some git-based tools can’t handle passwords, but this can sometimes be
worked around by using public keys and a config file (
The git daemon is the recommended tool for a more permanent setup, or you can configure a production-ready server like Nginx or Apache to replace Python’s SimpleHTTPServer.
More details are here.