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

41–50 of 95 posts

Re: Mounting Git commits as folders with NFS

#41

Post by donaldihunter »

codewiz wrote: post #27
bigstrat2003 wrote: post #10

Earlier quoted context omitted.

It also reminds me of ClearCase, which is why I kind of hate this, lol. ClearCase is fucking awful to work with, the last thing I want is to turn git into it.

Several years ago, one of my customers deployed Rational ClearCase across the company. Every employee and consultant, me included, was signed up for a week-long course on how to use the "Rational Unified Process" and other nonsense like that. By day 2, it was clear that they were selling us snake oil, but my customer was paying for my time, so I sit through it to the end. A few engineers in the room were genuinely ho…

Yeah, that's mostly nothing to do with ClearCase tho. Raw ClearCase was just a VCS. It was Unified Change Management (UCM) that brought in the Rational Unified Process garbage.

Re: Mounting Git commits as folders with NFS

#42

Post by globular-toast »

cnity wrote: post #36
divbzero wrote: post #23

Earlier quoted context omitted.

That’s a pretty cool feature of Magit. I was inspired to look for something similar for the next best text editor (vim) and came across this: https://salferrarello.com/using-vim-view-git-commits/ git log | vim -R - Placing your cursor over a commit hash and entering K displays git show for that commit.

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

You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Common Lisp and Scheme (Guile) are real contenders but the challenge is not giving up the enormous amount of useful code that is already written in Elisp.

Re: Mounting Git commits as folders with NFS

#43

Post by evgpbfhnr »

> 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 not necessarily exposed to userspace)

NFS servers can then just expose this along with some internal stuff (like export id for internal permissions checks etc)

This can lead to some interesting misfeature if a user can guess the handles -- on most filesystems it'll just be something like the inode number and some extra stuff that depending on the filesystem can be contiguously allocated, so +1 can work -- in that open by handle at won't check that the user has access to the full path: so a malign user could access some/subdir/file if file itself is open even if subdir isn't accessible. Thanksfully most recent filesystems allocate inodes pseudo-randomly, so this won't work well for most people.

(In this particular case, you could have commit id + a big hash table with paths inside the repo? Most recently large repos would fit in memory for one single revision and layout doesn't change all that much between commits, so that could work fairly well a bit past linux kernel size. For humongous repos some more tricks might be needed though)

Re: Mounting Git commits as folders with NFS

#44

Post by galangalalgol »

globular-toast wrote: post #42
cnity wrote: 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).

You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Co…

Does the elisp interpreter that runs emacs have jit?

Re: Mounting Git commits as folders with NFS

#45

Post by fourthark »

galangalalgol wrote: post #44
globular-toast wrote: post #42

Earlier quoted context omitted.

You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Co…

Does the elisp interpreter that runs emacs have jit?

Only with v28, a year or two ago.

Re: Mounting Git commits as folders with NFS

#46

Post by cnity »

globular-toast wrote: post #42
cnity wrote: 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).

You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Co…

I'm a big lisp fan. I know about all of this, I used emacs for maybe a decade, and I still don't like elisp. I love the hackability of Emacs, but it's OK to dislike the language itself. Disliking semantic choices of the language doesn't mean I'm missing the point either!

And on "it's not just an extensibility language": in my experience this doesn't matter. I get that "well the editor itself is half written in elisp" and so vaguely that is superior, but it is only so in an academic sense.

Expose the primitives for the editor in some API in _any_ langauge and you can basically achieve the same thing anyway, so pick a language that doesn't make me want to poke my eyeballs out with a hot skewer.

Sorry, rant over.

Re: Mounting Git commits as folders with NFS

#47

Post by colejohnson66 »

AceJohnny2 wrote: post #9
masklinn wrote: 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…

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?

Re: Mounting Git commits as folders with NFS

#49

Post by globular-toast »

cnity wrote: post #46
globular-toast wrote: post #42

Earlier quoted context omitted.

You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Co…

I'm a big lisp fan. I know about all of this, I used emacs for maybe a decade, and I still don't like elisp. I love the hackability of Emacs, but it's OK to dislike the language itself. Disliking semantic choices of the language doesn't mean I'm missing the point either! And on "it's not just an extensibility language": in my experience this doesn't matter. I get that "well the editor itself is half written in elisp"…

I think if you're just talking about writing extensions/packages (like magit) then the difference is not as big. But for using Emacs it makes a big difference. I can just start hacking on package code by redefining functions etc. and using/testing them straight away. The power of Emacs is not about being able to write extensions (most editors can do that), it's about being able to write tiny little bits of code to change your editing experience as you go. There are specific things in Elisp that make it good for this, like dynamically scoped variables. Writing extensions for other editors is always a "thing", a project. Writing Elisp to change how Emacs works is just using Emacs.

Re: Mounting Git commits as folders with NFS

#50

Post by trollied »

donaldihunter wrote: post #39
trollied wrote: post #4

Reminds me of Rational ClearCase, which probably inspired the idea. You could specify a "view" using tags, and it'd present it as a filesystem to remote machines. I think IBM now own them.

Clearcase also had version extended naming so you could access a specific revision as sort.c@@/main/bugfix/4 or tag as sort.c@@/RLS_1.3

That was great for diffing/creating patches etc. A gitfs that exposed a repos files like that would be great, but I suspect there are patents.
Post reply on HN