The screenshot looks nice but I can't figure out how to get it working. I can mark files with TAB but how can I edit/stage/commit? The ALT-X hotkeys create characters which are used to refine the search.
Depends on how your terminal is set up. Often times folks remap those keys and that prevents `fzf` from receiving them. If that’s the case, try a new terminal emulator as an experiment.
I tried the macOS terminal, iTerm2, and the xterm that ships with XQuartz. None of them work. I think the problem is that by default Alt+X creates printable characters on macOS.
For example:
Alt-E => €
Alt-U => ¨
Alt-C => ç
Disabling this is not really an option because I rely on them.
Option as Meta "solves" that in prefs. In quotes because Terminal.app makes it apply to both Option keys so you can't have it as modifier to enter special chars at the same time on the other key (iTerm2 has such an option). This makes that checkbox useless on e.g French layout (which has the pipe, tilde, square brackets, and braces behind Option).
Meta+<key> is actually sending ESC char followed by <key char> veryfastantaneously, so ESC+<key> (at almost the same time, and in that order) works, which has saved me from time to time.
Also see timeoutlen in vim, keyseq-timeout in inputrc/deadline, maptimeout in screen, and escape-time in tmux.
The doc seems to imply if I have delta installed, it will just automatically use it. But that doesn't seem to be the case, git fuzzy log output looks the same with and without? I have my git pager set to use delta, so I know it works.
I believe I ran into the same thing. If the other commenter is anything like me, the underlying cause is that `delta` did not support unified diffs until version 0.0.15 (ie only for the last 6 months).
I don't even remember when I installed delta the first time, since I ultimately liked ydiff better for side-by-side diffing with line-numbers. I thought I'd give delta a try again only because of this fzf endorsement of it (context is a little different, too, obviously).
My perfect diff tooling would support both drop-in replacement for `diff` but unfortunately I still haven't found the one that checks all the feature boxes I want yet. But this fzf wrapper is AWESOME! I tried to do something similar a few months ago and ran out of steam. Glad you didn't!
Anyway, updating delta to latest did the trick for me. Note that if you are using homebrew, the formula name is git-delta
Magit on emacs is hands down the greatest interface to git that has ever been conceived. Vim + Fugitive doesn't even come close (sorry, tpope, I still love you).
So much so that I started using emacs with evil-mode, so that I can use my vim muscle memory and have access to magit. That is how good magit is. It literally converted me to the light (dark?) side.
Magit's user interface has a status screen, from which you can perform the git commands.
In short, I think it's got the best of both a GUI or a CLI interface:
If you're unfamiliar with which magit commands you want to run, its interface is highly discoverable: it can list all the commands you can run, and for each of these it lists the most common options. (Some more advanced options are hidden but can be configured to show).
Once you're familiar with the commands you want to run, they can be run by typing the sequences of keys directly. (e.g. `c c` to commit, `c w` to reword, `r -i e` to start an interactive rebase onto another branch, etc.). -- This is the speed of having two letter aliases on the CLI, but without having to set them up.
This combined with the other dynamics that you get from having its interface in a text editor:
With a CLI, I'd have to type out a commit's hash (3 or 4 letters) to operate on it; with magit, I can operate with a commit by having my cursor on it.
When choosing a branch, emacs' narrowing tools are better integrated than what you get out of the box with CLI.
Because it's part of the Emacs editor, you can write custom convenience functions which build on top of the functionality if you want.
With a simmering case of emacs chord key induced RSI I recently tried to make the switch to vim. The big thing I missed was magit, vim's port left me wanting, and the other tools just seemed like git cli embellishments. Just when I thought I was out, magit drew me back in.
Anyway, the screenshots from the OP make this project look like a very worthwhile undertaking. I can see why, perhaps frustratingly for the present project's author, this provoked a discussion on magit.
Thanks for the suggestion I will give this a try. I currently have Esc + <some key> bound to some of my most common actions. For me the 80/20 rule seems to apply to emacs shortcut keys, so making just a couple of them easier has a big impact.
I do believe it is the most well thought out porcelain to git that I have ever come across, in any editor that I've seen. The ability to integrate nearly all the various git CLI tools (not to mention forge, the magit plugin that integrates with github/gitlab) into one cohesive interface is incredible.
Many blog posts have been written about the features of magit, so I wont attempt to enumerate them here.
I'm a vim + fugitive user who tried emacs for a year about 2 years ago. I eventually moved back to vim but the thing I miss from emacs is magit. It made so much sense to me. Loved it.
I think they serve a mostly different purpose. Fugitive provides vim integration, but you're supposed to use the stock CLI for a lot of operations. Magit, on the other hand, strives to provide an alternative interface for git. The surprising thing about Magit is that while it does provide an alternative interface, it does it in a way that's flexible enough that you won't have to constantly fall back to the CLI. Plus, its UI has good discoverability.
What I find superior about Magit is that it has asynchronous git blame. With Fugitive, git blame can take an unpredictably long amount of time with large repositories. It also used to be that this made vim unresponsive to any form of input and the only way to interrupt it was to terminate the vim process externally. This fortunately isn't the case now with recent versions of Fugitive, but it still blocks the editor unless you interrupt it. Magit doesn't have this issue and can show the git blame results as it's being computed.
In terms of cost to entry though, I think Fugitive is better in this regard. With Fugitive, you can get started almost immediately if you're familiar with the git CLI. On the other hand, you would sometimes need to look up how to accomplish some things with Magit because it sometimes uses different terminology from stock git.
How is the state of Magit on MS-Windows? For me it's unusably(!)
slow with a 3-4 GB repository. What is the best way to run Emacs on Windows? I'm using
cygwin because I need so many unix tools anyway.
Magit makes a ridiculous amount of forks for even trivial git commands, and Windows doesn't handle it well.
For me, emax64 works perfectly in Windows, although I don't use magit on it. Beyond magit, I see no difference between my Windows and my Linux emacs usage.
You can do the split in subversion by filtering the paths, and keeping the history :-) There is a svnadmin command for that. I guess you can do something similar in git
The magic is inside git-subtree (invoke as `git subtree split -P path/prefix/of/subtree/to/decouple -b branch-name-to-create-and-store-subtree-history`). There is also more exotic stuff that would just rip a complete folder out, but that get's complicated.
It works just fine for me (though my repos are small), however it is extremely slow when ssh'ing through Tramp onto a Linux host. I still put up with it because the interface is so good.
It works great on WSL2, if your IDE (or editor, which can be the same Emacs) is also inside the WSL environment.
I don't remember how the performance was in WSL1 (I switched as soon as WSL2 was in the insider build, for unrelated reasons), but I vaguely remember it worked ok, as in performance was snappy just like on native linux. (The repo is of comparable size, 2-4GB)
Nice! I've been using my own `git fzsha` and `git fzfile` commands pretty much since I discovered fzf, as prefixes to standard commands which they pass the fzfound result on to. I just recently moved them out to their own repo (https://github.com/OJFord/fzutils) having been asked about it a few times, but looks like I might be able to drop them in favour of this.
I tried to look at the web page but it has ~16MB in 3 images (please don't do that) and blew up my palemoon process by over 3GB (not MB). I have never seen that before. JS is disabled. There's something really nasty going on. Browser is palemoon, fairly recent.
I checked again and it's actually about 4GB. It has to be a browser fault. There's no reason for it. The images shouldn't lead to that, and probably don't.
As for the images, point for me is they actually told me nothing useful. It's just animated text, and there's little I can take from them. Perhaps a series of static images, annotated, would be more helpful. IMO
I recommend you check out the log command. It’s quite powerful and the closest to a “git history search engine” I’ve ever seen.