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

21–30 of 95 posts

Re: Mounting Git commits as folders with NFS

#21

Post by masklinn »

mbakke wrote: post #6

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool: > searching for a function I deleted git log -G someFunc > quickly looking at a file on another branch to copy a line from it I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use: git show $REF:$FILENAME > sea…

> searching for a function I deleted

> git log -G someFunc

This will look for all changes mentioning someFunc throughout the history of the project.

Usually -S is more valuable, as it will look for changes in occurrence counts. So if you moved a call in a commit -G will flag it, but -S will ignore it (+1-1 = 0).

-S also defaults to fixed string, so no need for -F. Instead you need —pickaxe-regex to switch it to regex search.

Re: Mounting Git commits as folders with NFS

#22

Post by ongy »

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.

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.

Re: Mounting Git commits as folders with NFS

#23

Post by divbzero »

globular-toast wrote: post #12
mbakke wrote: post #6

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool: > searching for a function I deleted git log -G someFunc > quickly looking at a file on another branch to copy a line from it I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use: git show $REF:$FILENAME > sea…

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.

Re: Mounting Git commits as folders with NFS

#24

Post by masklinn »

globular-toast wrote: post #12
mbakke wrote: post #6

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool: > searching for a function I deleted git log -G someFunc > quickly looking at a file on another branch to copy a line from it I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use: git show $REF:$FILENAME > sea…

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…

My bread and butter is jumping via blame, though I don’t really like emacs’ blame view so I generally use intellij or git gui.

e.g. see something odd / interesting, activate blame view, and “show diff” / “annotate previous revision” to see how the hunk evolved. Often this provides fast-tracking through the file’s history as the hunk goes through inconsequential changes (e.g. reformatting, minor updates) without changing the gist of what sparked your interest.

Re: Mounting Git commits as folders with NFS

#26

Post by masklinn »

CodeCompost wrote: post #17

IMO one of the major flaws of Subversion is that branches are folders.

OTOH it’s also a major advantage of subversion, because if you have long-running branches and need to fix something in all of them all the fixes can be in the same commit across every branch instead of needing a commit in each branch informally linked to the previous one (or formally so via a merge commit if every fix in an older branch has to get ported forwards, as an empty commit if not applicable).

Re: Mounting Git commits as folders with NFS

#27

Post by codewiz »

bigstrat2003 wrote: post #10
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.

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 hooked up by the promise of generating 90% of the code from UML, integration streams, automatic "un-branching" and all that.

I wonder what they spent overall in licensing fees, training and lost productivity? And that's probably a fraction of the long-term damage dealt by this absurd process to a large C++ codebase.

Somewhere, I should still have a "degree" issued by Rational University :-)

Re: Mounting Git commits as folders with NFS

#28

Post by masklinn »

okl wrote: post #8

Git already has a similar feature. It's called worktree https://git-scm.com/docs/git-worktree For example: `git worktree add ` checks out that commit in that folder.

Worktrees require checking out each branch individually.

And they’re something of a pain in the ass to manage as you can’t have two worktrees to the same branch.

So for temporary querying across a few branches doing clones is a lot easier (git will hardlink when cloning on the same FS so performances are not an issue, and you can just delete the scratch clones afterwards without the need to prune the worktrees), and if you regularly need to query things across a lot of branches worktrees are unusable.

Re: Mounting Git commits as folders with NFS

#29

Post by dag11 »

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.

Re: Mounting Git commits as folders with NFS

#30

Post by bmacho »

eru wrote: post #3
reverius42 wrote: post #2

Very nice! I really like the design choices here. Though I (edit: am biased and) would personally have used Rust and https://github.com/xetdata/nfsserve .

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?

Post reply on HN