Live data from Hacker News

Mounting Git commits as folders with NFS

jvns.ca

11–20 of 95 posts

Re: Mounting Git commits as folders with NFS

#12
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 than the current one. So many people think of it simply as the annoying tool you have to use to make code changes but don't really know what version control is.

Re: Mounting Git commits as folders with NFS

#13

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 .

Functional but not complete. The project is looking for maintainers. Overall it is a pity how so many potentially great Rust projects are inactive and left in incomplete state.

Re: Mounting Git commits as folders with NFS

#16
post #13

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 .

Functional but not complete. The project is looking for maintainers. Overall it is a pity how so many potentially great Rust projects are inactive and left in incomplete state.

It's not complete in its current state with respect to the NFS protocol, but is very usable as a base for things that work (for instance, https://github.com/xetdata/xet-core uses it to mount git(-xet) repos as directories, similarly to the linked post but with some different design choices). It is maintained for this use case and contributors are welcome for other use cases that aren't covered yet.

Re: Mounting Git commits as folders with NFS

#18
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.

I find it helpful to keep a few worktrees around for common tasks.

This saves me from throwing away my working copy when I switch to a different task;

  /source/repos/AcmeCorp            2fddd74f9a [bug/CurrentWork]
  /source/repos/AcmeCorp-hotfix     27175cf6c5 [hotfix/2023-11-27.1]
  /source/repos/AcmeCorp-master     016ca20b75 [master]
  /source/repos/AcmeCorp-reference  454be5348d [feature/RecentReviewedWork]
  /source/repos/AcmeCorp-release    95027177d7 [release9.12.0]

Re: Mounting Git commits as folders with NFS

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

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

Post reply on HN