Fun project to hack on, but strikes me as kind of pointless beyond the experience/academic value of making it.
There are already a number of read-only FUSE-git bridges, and we already have production-ready FTP daemons galore if that's the protocol you prefer.
If you don't like the existing FUSE-git bridges make one of those instead. It's more composable; you could also point apache at the read-only FUSE mount for example.
You're unnecessarily tightly-coupling libgit2 and the FTP protocol, and probably creating a bunch of bugs (potentially dangerous RCE ones being a network service) in the process.
I would love to have some kind of protocol standardized for this. Having done some work on build/packaging tooling for the ROS ecosystem, there are a bunch of cases where we we need to access a metadata file (for dependency resolution) or grab a tarball from a remote repo and end up having to have multiple implementations to handle the slight differences between Github, Gitlab, and Bitbucket, plus a fallback option that actually does a local clone, see:
I have hit similar problems multiple times in the past. So I'd be happy if there was a standard git server that is worth its name. SVN did that part right by using WebDAV, so any HTTP client is enough to grab a the contents of a file from there. It is a shame that git doesn't have anything sinilar out of the box almost 20 years later. Even hg has an embedded http that can provide this.
I feel like something went wrong a few steps ago if you find yourself needing this.
Happy to be enlightened otherwise?
I find it hard to criticize these sorts of projects. I think people should be questioned about strange ideas but over the internet it's hard to convey tone and hard to explain that I still want to encourage them to continue work on the weird, strange and unique.
In principle, the decentralized nature of git means that you don't really have to do this sort of thing. Just clone and be done.
But in practice, I do often find myself browsing my own code on GitHub for a variety of reasons:
- I'm in their office at their machine, but didn't bring my laptop.
- I'm traveling and want to talk about something with someone (I travel with a separate laptop).
- I'm half way through a big refactor and want to go back and see what master looks like. I know how to do this without GH/GL, but the simplest way to do that is to just pull up GH.
In all of these cases, and others, it's far easier to just pull up the file on github than it is to clone the repo locally.
So, given that we do sometimes want to browse our code remotely, the author then provides the (rather niche) criteria that make this a better solution than GH/GL:
"By serving a repo behind an FTP interface, we get these benefits:
- Web browser supported but not required
- Minimized network traffic, sending just the file data itself
- Supported on all platforms, with dozens of clients already written
- Support for both the command line and GUI"
Agree with you that this is a fairly niche set of criteria, but I could at least imagine myself in an environment where this could be a useful tool.
I think you are a bit quick to judge to declare this as "strange" and "weird".
What I find strange for myself is the requirement of having a git web interface installed on the server and the need to use a web browser just to analyze a few parts of a remote repository.
Sure, it works, looks great, and there already are mainstream solutions available; but, a web interface certainly is overkill if all you want is to display some remote files.
I'm definitely not saying that web interfaces are wrong, but for people like me, simpler alternatives are very welcome, and I feel that FTP is a perfect fit for this. Git repositories are file trees after all and a "file transfer protocol" sounds like a better fit for this task than a "hypertext transfer protocol".
Apart from simplicity, this approach would have better composability (with external tools) as well, as the author put it:
> However these interfaces are fairly rigid, and don’t connect well with external tools.
Looking for simpler solutions to do things that we do everyday is never "strange" in my eyes.
I do this very often. Usually, I'm looking at a very large project (think glibc, WebKit, etc.) trying to find a certain thing (where is this output coming from, what code path leads to this behavior?); so I really only need to look at a couple of files. It's really not worth cloning the entire project for one little thing.
I don't know much about the <video> tag, but in Safari I just see a very fuzzy screenshot, leaking off the right edge of the page. Clicking it does nothing, either.
In a real scenario gitftp would be run remotely. If you're hosting your own git server then you could host the ftp interface too. It won't work with e.g. Github.
I would be much more comfortable with using this if it was written in Go or Rust. Why are we still writing C programs to expose sensitive information when much safer languages exist to handle these?
Author here. I did aim to write the code carefully, for instance doing bounded reads like `fgets(cmd, CLIENT_BUFSZ, conn)` to prevent overflowing my buffer. Also ran the program in Valgrind and exercised different code paths to detect memory leaks and management errors such as use-after-free or double-freeing. Because libgit2 and its memory conventions were new to me, I did actually make mistakes and Valgrind helped me find them. The fix for those mistakes is in commit 59bb39b if you're curious to check it out.
Writing in C requires care, but the modern day "rewrite it in rust" crusade does feel overblown. C programs are nice -- small and fast.
Anyway, I don't mean to be cocky. A code review is welcome, I'd be curious if I did indeed overlook a security issue.
[+] [-] newnewpdro|7 years ago|reply
There are already a number of read-only FUSE-git bridges, and we already have production-ready FTP daemons galore if that's the protocol you prefer.
If you don't like the existing FUSE-git bridges make one of those instead. It's more composable; you could also point apache at the read-only FUSE mount for example.
You're unnecessarily tightly-coupling libgit2 and the FTP protocol, and probably creating a bunch of bugs (potentially dangerous RCE ones being a network service) in the process.
[+] [-] mikepurvis|7 years ago|reply
https://github.com/ros-infrastructure/rosdistro/tree/master/...
https://github.com/ros-infrastructure/rosinstall_generator/b...
[+] [-] gmueckl|7 years ago|reply
[+] [-] lugg|7 years ago|reply
I feel like something went wrong a few steps ago if you find yourself needing this.
Happy to be enlightened otherwise?
I find it hard to criticize these sorts of projects. I think people should be questioned about strange ideas but over the internet it's hard to convey tone and hard to explain that I still want to encourage them to continue work on the weird, strange and unique.
[+] [-] throwawayjava|7 years ago|reply
But in practice, I do often find myself browsing my own code on GitHub for a variety of reasons:
- I'm in their office at their machine, but didn't bring my laptop.
- I'm traveling and want to talk about something with someone (I travel with a separate laptop).
- I'm half way through a big refactor and want to go back and see what master looks like. I know how to do this without GH/GL, but the simplest way to do that is to just pull up GH.
In all of these cases, and others, it's far easier to just pull up the file on github than it is to clone the repo locally.
So, given that we do sometimes want to browse our code remotely, the author then provides the (rather niche) criteria that make this a better solution than GH/GL:
"By serving a repo behind an FTP interface, we get these benefits:
- Web browser supported but not required
- Minimized network traffic, sending just the file data itself
- Supported on all platforms, with dozens of clients already written
- Support for both the command line and GUI"
Agree with you that this is a fairly niche set of criteria, but I could at least imagine myself in an environment where this could be a useful tool.
[+] [-] gwn7|7 years ago|reply
What I find strange for myself is the requirement of having a git web interface installed on the server and the need to use a web browser just to analyze a few parts of a remote repository.
Sure, it works, looks great, and there already are mainstream solutions available; but, a web interface certainly is overkill if all you want is to display some remote files.
I'm definitely not saying that web interfaces are wrong, but for people like me, simpler alternatives are very welcome, and I feel that FTP is a perfect fit for this. Git repositories are file trees after all and a "file transfer protocol" sounds like a better fit for this task than a "hypertext transfer protocol".
Apart from simplicity, this approach would have better composability (with external tools) as well, as the author put it:
> However these interfaces are fairly rigid, and don’t connect well with external tools.
Looking for simpler solutions to do things that we do everyday is never "strange" in my eyes.
[+] [-] saagarjha|7 years ago|reply
[+] [-] sandov|7 years ago|reply
"You're holding it wrong"
[+] [-] joseph8th|7 years ago|reply
I'm curious to try this out!
[+] [-] funkaster|7 years ago|reply
[+] [-] telotortium|7 years ago|reply
[+] [-] aepiepaey|7 years ago|reply
Just prepend sourcegraph.com/ to the hostname. That'd be https://sourcegraph.com/github.com/user/repo for your example.
It can be self-hosted as well.
[+] [-] saagarjha|7 years ago|reply
[+] [-] ken|7 years ago|reply
[+] [-] begriffs|7 years ago|reply
Thanks for reporting this. It looks ok for me in Safari 12.0.3, what version are you on?
The bulk of the work is done by Video.js 5.0.2. Perhaps your browser or plugins are blocking the script?
Can you send me an email with a screenshot? I do try to make the videos work on every browser if possible.
[+] [-] gwn7|7 years ago|reply
Example (Gopher link):
gopher://bitreich.org/1/scm/stagit-gopher/log.gph
[+] [-] arjun27|7 years ago|reply
[+] [-] mochja|7 years ago|reply
https://github.com/mochja/giftp
[+] [-] clinta|7 years ago|reply
[+] [-] gwn7|7 years ago|reply
[+] [-] notaboutdave|7 years ago|reply
[+] [-] begriffs|7 years ago|reply
[+] [-] black-tea|7 years ago|reply
[+] [-] nicklaf|7 years ago|reply
[+] [-] xvector|7 years ago|reply
[+] [-] begriffs|7 years ago|reply
Writing in C requires care, but the modern day "rewrite it in rust" crusade does feel overblown. C programs are nice -- small and fast.
Anyway, I don't mean to be cocky. A code review is welcome, I'd be curious if I did indeed overlook a security issue.