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?
https://filehamster.com/ Maybe?
Mounting Git commits as folders with NFS
61–70 of 95 posts
Re: Mounting Git commits as folders with NFS
#62Is 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.
File handle refcounting would be nice to avoid spamming Git with commits, indeed.
Re: Mounting Git commits as folders with NFS
#63Earlier quoted context omitted.
Does the elisp interpreter that runs emacs have jit?
Only with v28, a year or two ago.
That's not a JIT. It uses `libgccjit` (IIRC the name), but the native code is produced ahead-of-time. JITs compile using info available on runtime, and native-comp doesn't do that. LuaJIT, by contrast, is a "real" JIT. Still, native-comp does speed things up considerably.
Re: Mounting Git commits as folders with NFS
#64Earlier 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.
Or I could use magit inside the best implementation of the vi standard.
Re: Mounting Git commits as folders with NFS
#65Earlier quoted context omitted.
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.
For me, even when working on something besides my editor configuration, having access to the parts of the “editor primitives” makes for a lot of powerful one-off editing tools. It was relatively easy, for example, for me to us lsp features to get a list of undefined JS variables in the current scope and add them to the function argument list. And, since lsp and the other bits I put together are all in elisp, I could use jump-to-definition to quickly find the itnernals I need to make the change.
Re: Mounting Git commits as folders with NFS
#66Earlier 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…
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 chang…
vc-annotate in emacs is my favorite blame view I’ve seen, if you haven’t tried it.
Re: Mounting Git commits as folders with NFS
#67Earlier 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).
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 (either in Lua or in the host app) when your codebase grows and complexity increases. Elisp provides two orders of magnitude more "bells and whistles" than Lua out of the box. Additionally, while Lua's primitives are extremely powerful, they are all strictly run-time constructs. Elisp has macros, so many abstractions can be (and are) shifted to compile time.
I use Awesome WM. It's essentially an "Emacs of Window Managers," and the codebase is very well written, with a small C core and everything else implemented in Lua. It's even very well documented. Yet, writing a nontrivial program (call it an "applet" or something) for Awesome is a nightmare compared to doing the same in Emacs.
LuaJIT is an excellent runtime, and Lua is a great IR, but writing it by hand for anything that's not strictly scripting within a previously established framework is challenging. It's to the point where I'm using Haxe to produce Lua for my Awesome scripts. I know a few people who use Haxe to script NeoVim, too. Really, having to reinvent inheritance and method resolution order every time you start writing Lua in a new project gets old fast.
I genuinely like Lua as a language - the same way I like Tcl, Scheme, and Io. They are all beautiful and powerful and perform very well in some scenarios. Elisp is ugly in comparison, but it's way more practical for medium-sized codebases. Being tied to Emacs is a considerable downside which limits its applicability, but focusing on language features alone, larger codebases are more practical to write in Elisp than in Lua. Plus, there's an escape hatch - Common Lisp or Clojure, pick your poison - for cases where Elisp actually doesn't cut it. There's no such easy way out for Lua.
Re: Mounting Git commits as folders with NFS
#68Earlier quoted context omitted.
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.
For me, even when working on something besides my editor configuration, having access to the parts of the “editor primitives” makes for a lot of powerful one-off editing tools. It was relatively easy, for example, for me to us lsp features to get a list of undefined JS variables in the current scope and add them to the function argument list. And, since lsp and the other bits I put together are all in elisp, I could…
What you're describing is a feature of the system as a whole. You can have the same workflow with any dynamic, reflective environment. All Smalltalks give you the same ability to "jump to definition" of anything, turtles all the way down, and fiddle with those definitions. You could have the same ability in a system written in Lua - you just generally don't, because it requires designing the system as a whole specifically to allow it.
Re: Mounting Git commits as folders with NFS
#69Earlier quoted context omitted.
For me, even when working on something besides my editor configuration, having access to the parts of the “editor primitives” makes for a lot of powerful one-off editing tools. It was relatively easy, for example, for me to us lsp features to get a list of undefined JS variables in the current scope and add them to the function argument list. And, since lsp and the other bits I put together are all in elisp, I could…
What you're describing is a feature of the system as a whole. You can have the same workflow with any dynamic, reflective environment. All Smalltalks give you the same ability to "jump to definition" of anything, turtles all the way down, and fiddle with those definitions. You could have the same ability in a system written in Lua - you just generally don't, because it requires designing the system as a whole specifi…
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.
Re: Mounting Git commits as folders with NFS
#70Earlier quoted context omitted.
What you're describing is a feature of the system as a whole. You can have the same workflow with any dynamic, reflective environment. All Smalltalks give you the same ability to "jump to definition" of anything, turtles all the way down, and fiddle with those definitions. You could have the same ability in a system written in Lua - you just generally don't, because it requires designing the system as a whole specifi…
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 and a few simple instructions for others to get it.