Live data from Hacker News

Mounting Git commits as folders with NFS

jvns.ca

71–80 of 95 posts

Re: Mounting Git commits as folders with NFS

#71

Earlier quoted context omitted.

Sure, but I’m not particularly defending emacs lisp (would prefer Common Lisp). It’s not exactly true that any language can have it, though: the language has to be designed to handle redefinition correctly.

> the language has to be designed to handle redefinition correctly. I believe it's more a question of how easy the redefinition is to implement. You can live-update a running Java or C programs, it's just less convenient/harder to pull off than with Forth, Smalltalk, Lisp, Prolog, and the like. So I think that yes, in principle, every language could have it - it's just that you'd need a huge pile of hacks for some an…

I think it’s basically impossible to safely live-patch part of a compilation unit in most programming languages: you’d have to account for inlining and other optimizations to do this correctly. You _can_ patch at linkage seams and other places, but this is a fraction of the sorts of redefinitions that you get easily in systems designed for it. (And I’ve spent a lot of time trying to make various programming languages more Lispy so I can get stuff done: you always discover there are static presumptions that make it impossible to get the full experience)

Re: Mounting Git commits as folders with NFS

#72

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. :)

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 two, no matter whether you happen to be using a GUI or terminal at the moment.

Re: Mounting Git commits as folders with NFS

#73
post #36

Earlier quoted context omitted.

If you're not using neovim you're really missing out right now IMO. It's a renaissance for a hackable text editor because it uses a sensible modern programming language (Lua) rather than vimscript (yikes) or elisp (eh).

Having worked with Lua and Elisp extensively, they have very different pros/cons profiles. In my experience, Lua is great as a scripting language - tiny, speedy, and completely dynamic. For "programming in the large(r)," Lua is just a little better than early JavaScript (i.e., tragic). The purity of the design - tables, metatables, closures, coroutines, and that's it - necessitates reinvention of tens of wheels (eith…

> There's no such easy way out for Lua.

I think there are some Lisp/Clojure inspired languages developed for Neovim which are used in Lua.

https://github.com/Olical/conjure

https://github.com/Olical/aniseed

https://github.com/Olical/nfnl

Re: Mounting Git commits as folders with NFS

#74

Earlier quoted context omitted.

> the language has to be designed to handle redefinition correctly. I believe it's more a question of how easy the redefinition is to implement. You can live-update a running Java or C programs, it's just less convenient/harder to pull off than with Forth, Smalltalk, Lisp, Prolog, and the like. So I think that yes, in principle, every language could have it - it's just that you'd need a huge pile of hacks for some an…

I think it’s basically impossible to safely live-patch part of a compilation unit in most programming languages: you’d have to account for inlining and other optimizations to do this correctly. You _can_ patch at linkage seams and other places, but this is a fraction of the sorts of redefinitions that you get easily in systems designed for it. (And I’ve spent a lot of time trying to make various programming languages…

> I think it’s basically impossible to safely live-patch part of a compilation unit in most programming languages

There's no argument there; you're right. That's why V and Nim, for example, put reloadable things in a separate compilation unit and handle some things (global state at least) specially upon reload (if I understand what they do correctly.)

My point was that you can get quite close (sometimes with a massive pile of hacks and/or developer inconvenience), not that you can get the full experience (as in Smalltalk or Lisp) everywhere. Especially since the reloading being convenient is a large part of the experience, I think.

Re: Mounting Git commits as folders with NFS

#75
post #5

> Git repositories sometimes have submodules. I don’t understand anything about submodules so right now I’m just ignoring them. Submodules are interesting, because they’re next to unusable from a user perspective (they’re a pain to maintain and interact with unless you never ever update them) but they’re ridiculously simple technically which I assume is what made them attractive. A submodule is an entry in “.gitmodul…

I feel like submodules are one of Git's most misunderstood features. I agree that they're really not great for the use-case of "I have to work in a bunch of repos at the same time", but they're also not designed for that.

Submodules are a really good solution for problems that look like "this repo depends on some upstream repos that I don't control", and a bad solution for any other problem. They do what they were designed to do.

Imagine that your build-script needs to clone a bunch of third-party dependencies. So maybe you write some kind of clone.sh that loops through a bunch of Git repo URLs. Then later you want to also specify specific commit hashes, so you add a commit-ID field. Then you write a tool that makes it easy to update the fields in your clone.sh file. Guess what you've got? Git submodules.

Re: Mounting Git commits as folders with NFS

#76

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…

> 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-Users.git and All-Projects.git are "databases" for project configuration and user configuration, where for example external IDs (like usernames) are stored under the special `refs/meta/external-ids` ref/branch. This has the notable benefit that all configuration changes are tracked and auditable.

I believe git-appraise [3] also leverages special reference namespaces in Git for performing its review duties (but I don't know details) Edit: actually no, it "just" leverages git-notes.

[1] https://git-scm.com/docs/git-notes

[2] https://gerrit-review.googlesource.com/Documentation/note-db...

[3] https://github.com/google/git-appraise

Re: Mounting Git commits as folders with NFS

#77

Earlier quoted context omitted.

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. :)

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?

Re: Mounting Git commits as folders with NFS

#78

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?

> 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, I see a directory created in the terminal.

So pretty sure that, aside from rare exceptions, they're identical and synonymous. So as long as you're not dealing with an exceptional situation, the terminology is literally interchangeable.

> Why are there no folders from the command line?

For historical terminology reasons, mostly. By the time GUI's introduced a new terminology, all the terminal commands had long since been named.

I really don't understand what overall point you're trying to make. But if you create a directory in the terminal that shows up in the GUI as a folder, it's 100% perfectly correct to say you created a folder in the terminal. Because you did.

Re: Mounting Git commits as folders with NFS

#79

Is there a project that does the reverse of this, namely mounting a filesystem where every write to a file in the repository becomes a Git commit?

You mean like when nothing has the file open any more, or doing a commit with every flush to disk? I think the latter is a bit excessive. One of the FUSE implementations mentioned in this post may do something like that.

I tried this with mod_dav_svn back in the day and never really managed to convince myself that commit-on-write is a good idea.

Re: Mounting Git commits as folders with NFS

#80

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.

If it doesn’t increase revenue that they can tax at 30% they won’t bother to touch it.
Post reply on HN