5 ms·

But why? 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 t

by lugg 8y ago

But why? 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 8y ago
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.
- gmueckl 8y ago
  Tip for looking up other versions of a file in a local repository when you don't want to update to it: TortoiseGit on Windows can open the repo browser to show the state for a certain commit from the repository history window. Not a lot of people seem to know this. And to this date, I have found no other client with that capability.
saagarjha 8y ago
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.
gwn7 8y ago
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.
- pvg 8y ago
  FTP is not a better fit other than by sounding like it is. It barely has a reliable way to list directories whereas hypertext can actually structurally represent a tree.
  - gwn7 8y ago
    I'm definitely no expert but; what's wrong with FTP's "ls" command? Does it list the files "barely"?
    - pvg 8y ago
      Pretty much. It just gives you an unstructured blob of text. From the RFC: Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user. It works by convention and people writing piles of hairy code to over the years to make it behave. FTP is a really ancient protocol with many problems beside that. Much like short people, it got no reason to live.
      - 8y ago
sandov 8y ago
>I feel like something went wrong a few steps ago if you find yourself needing this. "You're holding it wrong"
- lugg 8y ago
  That's a big leap at best, misrepresentation at worst. Git is specifically a decentralised version control system. Cloning the remote branches is how you view and browse remote repos. Viewing remote non bare repos via FTP is fine but im not sure I understand the problem. The problem is network traffic? Cool, checkout a shallow copy depth=1. Browsing? I'm confused how ftp is worse than say GitHub? Or GitHub with some of the file browser add-ons/greasemonkey scripts. I'm also pretty confused by the use case that ftp beats keeping a local working copy. Presumably you want to edit these files eventually right? Are you also editing remotely? What about a remote X session or SSH? I'm just confused by the use case not saying you're holding it wrong. Try answering this: in what world or under which conditions does this solution make sense? I'm not saying it's wrong I'm saying I can't see what conditions make this make sense.

by lugg 8y ago

throwawayjava 8y ago

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.

gmueckl 8y ago
Tip for looking up other versions of a file in a local repository when you don't want to update to it: TortoiseGit on Windows can open the repo browser to show the state for a certain commit from the repository history window. Not a lot of people seem to know this. And to this date, I have found no other client with that capability.

saagarjha 8y ago

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.

gwn7 8y ago

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.

pvg 8y ago
FTP is not a better fit other than by sounding like it is. It barely has a reliable way to list directories whereas hypertext can actually structurally represent a tree.
- gwn7 8y ago
  I'm definitely no expert but; what's wrong with FTP's "ls" command? Does it list the files "barely"?
  - pvg 8y ago
    Pretty much. It just gives you an unstructured blob of text. From the RFC: Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user. It works by convention and people writing piles of hairy code to over the years to make it behave. FTP is a really ancient protocol with many problems beside that. Much like short people, it got no reason to live.
    - 8y ago

sandov 8y ago

>I feel like something went wrong a few steps ago if you find yourself needing this. "You're holding it wrong"

lugg 8y ago
That's a big leap at best, misrepresentation at worst. Git is specifically a decentralised version control system. Cloning the remote branches is how you view and browse remote repos. Viewing remote non bare repos via FTP is fine but im not sure I understand the problem. The problem is network traffic? Cool, checkout a shallow copy depth=1. Browsing? I'm confused how ftp is worse than say GitHub? Or GitHub with some of the file browser add-ons/greasemonkey scripts. I'm also pretty confused by the use case that ftp beats keeping a local working copy. Presumably you want to edit these files eventually right? Are you also editing remotely? What about a remote X session or SSH? I'm just confused by the use case not saying you're holding it wrong. Try answering this: in what world or under which conditions does this solution make sense? I'm not saying it's wrong I'm saying I can't see what conditions make this make sense.