Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mounting Git commits as folders with NFS

jvns.ca

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Mounting Git commits as folders with NFS

#81

Post by assimpleaspossi »

crazygringo wrote: post #78
assimpleaspossi wrote: post #77

Earlier quoted context omitted.

And yet you listed several reasons why folders are not directories and vice-versa. No computer system, from the command line, has a command that allows you to "make_folder" but every system has a "make_directory" (mkdir) or "change_directory" (cd) and so on. If there is little to no difference, then why is this so? Why are there no folders from the command line?

> And yet you listed several reasons why folders are not directories and vice-versa. No I didn't. I listed the exceptions where they are not the same thing. The fact that they're exceptions implies the existence of a rule, which is that they're usually the same. Generally speaking, every Mac and Windows system I use, when I create a directory, I see a folder created in the GUI. And when I create a folder in the GUI,…

And what happens when you are not using a GUI? Aren't you incapable of creating folders? If a folder is the same thing, why can't you create one then?

A folder does not exist without a GUI. A folder "might" represent a clickable interface that shows the same contents as a directory but a browser will read the contents of that directory using pathnames and not folders.

And mounting a disk drive onto a folder makes no sense at all.

Your "for historical reasons" is a made up reason unless you can point to an authoritative source for that. If nothing else, the source to Wikipedia in this thread says what I say and not what you wrote.

Re: Mounting Git commits as folders with NFS

#82

Post by assimpleaspossi »

dag11 wrote: post #29
assimpleaspossi wrote: post #20

I just hate these things where people use the terms "folder" and "directory" as if they were the same thing. They are not and I wish some people would wise up to that. Yes. This is a pet peeve of mine.

What's the difference? When I select "New Folder" on my computer's file browser, it creates a directory. Your comment is the first time I'm hearing they're not interchangeable.

What do you do when you don't have a GUI--you are on the command line--and there is no "New Folder" to select?

Do you mount a disk drive onto a folder? How does that make sense?

Re: Mounting Git commits as folders with NFS

#83

Post by DonHopkins »

emsimot wrote: post #25
assimpleaspossi wrote: post #20

I just hate these things where people use the terms "folder" and "directory" as if they were the same thing. They are not and I wish some people would wise up to that. Yes. This is a pet peeve of mine.

What's the difference?

On the Mac, a folder can have a "/" in its name, but a directory can't. Don't believe me? I bet you $10. Paypal my winnings to don@donhopkins.com please!

Re: Mounting Git commits as folders with NFS

#84

Post by crazygringo »

assimpleaspossi wrote: post #81
crazygringo wrote: post #78

Earlier quoted context omitted.

> And yet you listed several reasons why folders are not directories and vice-versa. No I didn't. I listed the exceptions where they are not the same thing. The fact that they're exceptions implies the existence of a rule, which is that they're usually the same. Generally speaking, every Mac and Windows system I use, when I create a directory, I see a folder created in the GUI. And when I create a folder in the GUI,…

And what happens when you are not using a GUI? Aren't you incapable of creating folders? If a folder is the same thing, why can't you create one then? A folder does not exist without a GUI. A folder "might" represent a clickable interface that shows the same contents as a directory but a browser will read the contents of that directory using pathnames and not folders. And mounting a disk drive onto a folder makes no…

Sorry, but this is just being overly pedantic without any practical value at all.

Of course you can create a folder without a GUI, because in all cases but a few exceptions, a folder is a directory. "mkdir" creates a folder, regardless of the name of the command. When I load my GUI later, I see the folder.

Until now, I have never knowingly met anybody who thought there was any value in drawing a distinction between the two for the basic purposes of routine file organization. So I think you're fighting a lost cause here.

Good luck with your crusade though! Sorry our usage of the term "folder" bothers you so much.

Re: Mounting Git commits as folders with NFS

#85

Post by creatonez »

assimpleaspossi wrote: post #82
dag11 wrote: post #29

Earlier quoted context omitted.

What's the difference? When I select "New Folder" on my computer's file browser, it creates a directory. Your comment is the first time I'm hearing they're not interchangeable.

What do you do when you don't have a GUI--you are on the command line--and there is no "New Folder" to select? Do you mount a disk drive onto a folder? How does that make sense?

> Do you mount a disk drive onto a folder?

Yes? It looks exactly the same as a folder in the UI either way.

Re: Mounting Git commits as folders with NFS

#86

Post by eru »

bmacho wrote: post #30
eru wrote: post #3

Earlier quoted context omitted.

I've built something like this as well, but in FUSE for Linux, not via NFS. It really brings home how close git's design already is to being a file system.

A virtual file system? How usable are those? I want something that can store slightly different data (modifies data on the fly), and one, that I can use as a tagged file system (generates folder structure on the fly). Is that viable with FUSE/NFS? Do programs play nice with them (no caching, no recursive lookahead and such)? Is it hard to write one? Which language did you used?

I wrote version in Python and Rust. (And ended up contributing to libfuse and its Rust equivalent along the way.)

> Do programs play nice with them (no caching, no recursive lookahead and such)?

Other programs play nice with my peculiar file systems as far as I can tell: they just look like ordinary files and directories and symlinks etc to them.

I don't know how well that would work for your usecase. Most of the caching etc that I am aware of happens at the layer of the Linux kernel, and your FUSE daemon can configure what caching it wants or doesn't want.

I don't know much about NFS. I only used FUSE directly.

For me, presenting git as a filesystem was relatively easy to write. I think that comes down to two main factors:

* Git's internal structure is very close to how Linux (and especially fuse) do filesystems. That's probably not a big surprise, given that git and the Linux kernel are both projects started by the same guy.

* I exposed the git data as a read-only filesystem. In general, if you can avoid mutation, you can avoid a lot of complexity. (The main source of complexity in the Python version I wrote first was that we allowed wanted to reflect changes in the contents of git branches to be reflected in the filesystem side. That's mutability flowing in only one direction (from git to the filesystem), but it was already annoying enough to deal with.)

On a more general note: I see filesystems mostly as one peculiar interface you can put in front of your data. So one some level git has an underlying database, and we just expose it. The same could be done for eg postgres or mongodb with a suitable fuse daemon.

But you can also think of ext4 being such a database with a weird UI layer on top. The main difference in practice is that they run their 'fuse daemon' in the kernel.

From what I've read the new bcachefs explicitly embraces this view of 'filesystems are just databases', and uses techniques borrowed from relational databases for its internal datastructures.

Re: Mounting Git commits as folders with NFS

#87

Post by EdSchouten »

evgpbfhnr wrote: post #43

> stale file handles... This is still a problem and I’m not sure how to fix it. I don’t understand how real NFS servers do this, maybe they just have a really big cache? While some implementations probably cache things, most filesystems have an underlying file handle which allow opening the file directly (see name_to_handle_at(2)/open_by_handle_at(2) on linux, but other systems also have something similar it's just n…

Worth mentioning that if you use NFSv4, file handles can be up to 128 bytes in size. That’s big enough that you can sometimes get away with dumping the entire file state in it.

For Buildbarn (a distributed build cluster for Bazel) I also wrote an NFSv4 server in Go to act as a lazy-loading file system for input files. As the remote execution protocol uses Content Addressable Storage, I ended up dumping the entire SHA-256, size and permission bits of files in the NFSv4 file handle. This allows me to reconstruct files as needed.

Some notes I made at the time (which are written with Buildbarn knowledge in mind):

https://github.com/buildbarn/bb-adrs/blob/master/0009-nfsv4....

Re: Mounting Git commits as folders with NFS

#88

Post by masklinn »

AceJohnny2 wrote: post #76
masklinn wrote: post #19

Earlier quoted context omitted.

> Branches are pointers to Commit objects Nit: the data model has refs, which are pointer to objects. Branches are the subset of refs in the special-cased heads/ namespace which should be pointing to commit objects. And there’s also tags, which are the subset of refs in the special-cased tags/ namespace, which should be pointing to commit (“lightweight”) or tag (“annotated”) objects.

Absolutely. Going further, the little-known git-notes [1] feature also uses its own reference namespace, `refs/notes/` Going even further, Gerrit [2] leverages the wide-open reference namespace/directories to create its own. For example, pushing under the `refs/for/` namespace creates a new review, and specific reviews can be looked up under the `refs/changes/` namespace. Even even further, Gerrit's special repos All…

GitHub also leverages refs, for each PR there are two magical refs in refs/pull// which point to the PR’s head and its prospective merged head

Re: Mounting Git commits as folders with NFS

#89

Post by assimpleaspossi »

crazygringo wrote: post #84
assimpleaspossi wrote: post #81

Earlier quoted context omitted.

And what happens when you are not using a GUI? Aren't you incapable of creating folders? If a folder is the same thing, why can't you create one then? A folder does not exist without a GUI. A folder "might" represent a clickable interface that shows the same contents as a directory but a browser will read the contents of that directory using pathnames and not folders. And mounting a disk drive onto a folder makes no…

Sorry, but this is just being overly pedantic without any practical value at all. Of course you can create a folder without a GUI, because in all cases but a few exceptions, a folder is a directory. "mkdir" creates a folder, regardless of the name of the command. When I load my GUI later, I see the folder. Until now, I have never knowingly met anybody who thought there was any value in drawing a distinction between t…

What you call pedantic I call technically correct. Nowadays too many people make up words that have no meaning and misuse words but think that's OK cause "you know what I mean". No, it is not clear what you mean using your Windows terminology while I'm working on my FreeBSD server attempting to mount hardware.

Re: Mounting Git commits as folders with NFS

#90

Post by assimpleaspossi »

creatonez wrote: post #85
assimpleaspossi wrote: post #82

Earlier quoted context omitted.

What do you do when you don't have a GUI--you are on the command line--and there is no "New Folder" to select? Do you mount a disk drive onto a folder? How does that make sense?

> Do you mount a disk drive onto a folder? Yes? It looks exactly the same as a folder in the UI either way.

What it looks like and what it is are two different things. A folder is a graphical representation. How do you stuff a hard drive into a paper, manila folder? How do I create a folder on a BSD server when there is no such term on a BSD server (but there is on a Windows machine)?

Why does even Windows use both terms if, as some want to claim, they have the same meaning? Why does Wikipedia state they are not the same thing?

Post reply on HN