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

91–95 of 95 posts

Re: Mounting Git commits as folders with NFS

#91

Post by boffinAudio »

avgcorrection wrote: post #57
arbitrandomuser wrote: post #31

Earlier quoted context omitted.

> Please don't just rant about it, but explain, or link to an explanation, the difference so others can see if there's actually a substantial difference. Fairly easy to look up and I just did , https://stackoverflow.com/questions/5078676/what-is-the-diff... but I agree , comments like this come across as smug and unhelpful. A few short lines explaining and a link would have been much helpful and greatly improves the…

The top answer > > There is a difference between a directory, which is a file system concept, and the graphical user interface metaphor that is used to represent it (a folder). So there really is no difference in a technical (programmers talking) context. :)

There is no difference between a directory and a folder except the term used to refer to the special kind of file that can hold links to other files. :)

Bonus points if you can find any kind of modern user that knows the difference between a FILE and a FOLDER (directory) ..

Re: Mounting Git commits as folders with NFS

#92

Post by mdaniel »

tambourine_man wrote: post #35

I don’t understand why Apple doesn’t provide a rock solid first party FUSE implementation. This and a container story are the main things holding macOS back.

I believe both of your complaints have the same underlying cause: they are Linux-centric (that goes extra for the "container story" part since I doubt very seriously that you have a use case for running containerized Darwin executables)

I believe Apple's version of FUSE is https://developer.apple.com/documentation/fileprovider/nonre... and, while I am absolutely certain someone will point out things that FUSE has that the macOS version doesn't, I'm only saying that, just like Windows, macOS has its own way of doing things and thus very little incentive to implement someone else's vision

Re: Mounting Git commits as folders with NFS

#93

Post by AceJohnny2 »

colejohnson66 wrote: post #47
AceJohnny2 wrote: post #9

Earlier quoted context omitted.

To add to this, Submodules are a hack on Git's data model. Git's data model, put simply, is this: * Branches are pointers to Commit objects * Commit objects are a composite of {Commit_Comment, Tree, Parent Commit(s)}, referenced by the hash of that set * a Tree (like a directory) is a list of Blobs and/or Trees (associating filenames with them) referenced by the hash of its contents. * a Blob is a file, referenced by…

So, one could theoretically "embed" an older commit into their repository as a pointer (submodule folder)? And because Git knows what that commit ID means it will show it fine?

Unfortunately no, because of how it's a hack, and so extra logic had to be tacked on to support it (logic which the `git submodule` command implements).

I tried it out, and the local commit object just appears as an empty folder.

To try for yourself, do this:

    git init recursive-submodule && cd recursive submodule

    echo "foo" > file1 && git add file1 && git commit -m "Add file1"

    # this will have created an initial commit with hash 2d49d729. Then:

    git update-index --add --cacheinfo 160000 2d49d729fe39d1def8ce537d7efeeabbf3efb4f2 submodule && git commit -m "Add submodule"
The `update-index` command is the plumbing command for adding an arbitrary object, which I used to add the previous commit object. Since we only updated the index and not the workspace, git will note that the submodule is missing. You can then run `git restore .` to set the workspace to the state the history says (ie with the missing submodule)... but that just creates an empty directory.

Vanilla git won't try much further. To actually populate the submodule requires running `git submodule update --init`, and that requires a `.gitmodules` file, even for a local commit object.

(To learn more about plumbing commands like update-index, look at the Git Book chapter on Internal Git Objects: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects )

Re: Mounting Git commits as folders with NFS

#94

Post by dag11 »

assimpleaspossi wrote: post #77
crazygringo wrote: post #72

Earlier quoted context omitted.

Yeah, 99.9% of the time they are interchangeable. There are exceptions where a GUI folder doesn't have a corresponding directory (e.g. "Control Panel") or when a directory doesn't appear as a GUI folder (a mounted volume, maybe?). But if you're just talking about regular everyday use cases for organizing files, folders are directories and directories are folders. In those cases, there's zero reason to distinguish the…

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?

> 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?

But doesn't that prove the concept that they're the same thing? If they were different things, surely there would be a different command for creating a folder and versus creating a directory. But there's just one command, and nobody is going to make a command called `mkdirakafol` ("make directory a.k.a. folder"). Sometimes multiple names can mean the same thing.

Like, a "trunk" and a "boot" can refer to the same thing. So what you just said is like "my car has an Open Trunk button, not an Open Boot button, so surely those are different concepts."

I've fallen for xkcd 386...

Re: Mounting Git commits as folders with NFS

#95

Post by tambourine_man »

mdaniel wrote: post #92
tambourine_man wrote: post #35

I don’t understand why Apple doesn’t provide a rock solid first party FUSE implementation. This and a container story are the main things holding macOS back.

I believe both of your complaints have the same underlying cause: they are Linux-centric (that goes extra for the "container story" part since I doubt very seriously that you have a use case for running containerized Darwin executables) I believe Apple's version of FUSE is https://developer.apple.com/documentation/fileprovider/nonre... and, while I am absolutely certain someone will point out things that FUSE has tha…

Apple goes to great lengths to increase security while annoying its users. Containers could help in that regard. Having an app (and GUI too) run in a container of sorts could avoid the countless dialog boxes we’ve grown accustomed to.

Regarding FUSE, there have been many implementations for macOS, just not very good ones. I don’t see a fundamental limitation on XNU, Darwin, Mach.

I haven’t though of File Provider in this way, but maybe it’s a good solution. Apple seems reasonably committed to it so that’s encouraging.

Post reply on HN