Live data from Hacker News

Mounting Git commits as folders with NFS

jvns.ca

51–60 of 95 posts

Re: Mounting Git commits as folders with NFS

#51

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

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

On Windows, access to this is controlled by the confusingly named "Bypass traverse checking" (aka SeChangeNotifyPrivilege) permission (see for instance https://techcommunity.microsoft.com/t5/windows-blog-archive/... for some information about it; I recall once reading an article from either Raymond Chen or Larry Osterman explaining the naming of that permission, but can't find it at the moment).

Re: Mounting Git commits as folders with NFS

#53
post #46

Earlier quoted context omitted.

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 ch…

I will concede that you are probably a very different kind of Emacs user than I, since I pretty much exclusively used Elisp to set up and tune my editor to my liking as a totally independent act from actually using my editor to write programs.

Re: Mounting Git commits as folders with NFS

#54

Earlier quoted context omitted.

Magit has a really easy to use way to "step" through previous versions of files. It's usually bound to something like "C-f p". You get a read only buffer of the previous version open in the best text editor (emacs). You can then press n and p to step through next and previous versions of that file. Can be pretty useful! It's kind of funny, I think, how most git users don't seem to know how to access any version other…

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.

I've been told by my elders that when a vim user encounters an emacs supremacist, they must fight back. You can't just call it "the next best text editor".

Jokes aside, As a vim user of 6 years, I did learn just enough emacs for magit (TM) and have also been making quick bucks on the side teaching it to my friends , so I guess I can't help with the "fight back" part :-)

Re: Mounting Git commits as folders with NFS

#55
post #27

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…

Wow. Circa 1999 my software engineering class, the college class that has the distinction of being the only class I've ever taken that I'm pretty sure I now disagree with literally everything that was taught in it, had us using that software suite to try to do that.

I recall it made a very uncompelling case, on the grounds that it was putatively the future of software engineering, and you could hardly right-click on anything without the stupid thing hard crashing. Pro-tip: If your software is the future of software engineering, an engineering student using your software to do exactly what it was designed to do should not be able to crash it in under two minutes. And then keep crashing it.

But even when it was working, it was literally virtually impossible to so much as contort a student assignment into that model. I can't imagine working somewhere that insisted on building production software that way, and I'm shocked they're still finding enough chumps to stay in business with that complete and utter trip pipe dream.

(In a nutshell, the primary problem with such systems is that they do not account for the fact that every entity in a diagram is a cost. Every entity in a diagram needs to carry a value in excess of that cost, preferably comfortably so. Any methodology that insists on a totalizing view of the world in which everything must be in a diagram will produce diagrams so cognitively expensive that they are just a blurred mass of diagram entities no easier to understand than the underlying code. The people pushing these systems build nice little demo diagrams with 10-15 entities in them that are easy to understand, and then incorrectly attribute the ease of understanding to the fact that it is a diagram, rather than the fact the diagram only contains a handful of entities! Then they build systems based on the utterly incorrect belief that all diagrams are simple. The results are entirely predictable when you see it from this point of view. The part that's mindblowing is just how hard some people need to be beaten over their skull with the fact that diagrams aren't necessarily simple once they've ingested this idea, no matter how many hundreds of insanely complicated diagrams they stare at over the years....)

Re: Mounting Git commits as folders with NFS

#56
> The main reason I wanted to make this was to give folks some intuition for how git works under the hood. After all, git commits really are very similar to folders – every Git commit contains a directory listing of the files in it, and that directory can have subdirectories, etc.

> It’s just that git commits aren’t actually implemented as folders to save disk space.

Okay. So what. People are used to archive formats.

> git worktree also lets you have multiple branches checked out at the same time, but to me it feels weird to set up an entire worktree just to look at 1 file.

But one directory per commit is less weird.

Re: Mounting Git commits as folders with NFS

#57
post #22

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.

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

Re: Mounting Git commits as folders with NFS

#58

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?

doesn't seem like the project is in active development anymore, but there's gitFS: https://github.com/presslabs/gitfs

Re: Mounting Git commits as folders with NFS

#59
post #22

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.

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.

I thought technical people on HN would know the difference. Of course, my complaint is about technical people not knowing the difference and more evidence is here in the comments.

Re: Mounting Git commits as folders with NFS

#60
post #29

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.

[deleted]
Post reply on HN