Show HN: `fzf` * `Git` done right
github.com
github.com
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.
For example:
Alt-E => €
Alt-U => ¨
Alt-C => ç
EDIT: formatting
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.
https://github.com/bigH/dotfiles/blob/master/configs/core.sh...
In the meanwhile, I'll try to repro.
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
And we have an open issue for side-by-side view: https://github.com/dandavison/delta/issues/86. I definitely plan to get to it!
The next release of delta will also provide diff-so-fancy and diff-highlight emulation modes. See https://github.com/dandavison/delta/issues/205
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.
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.
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.
https://www.youtube.com/watch?v=7ywEgcbaiys
https://www.youtube.com/watch?v=j-k-lkilbEs
The second (long) one is from John Wiegley[1] whose various packages have a fairly high impact, so I expect the video will be very educational.
Many blog posts have been written about the features of magit, so I wont attempt to enumerate them here.
The README lists out several things that are missing that not only exist in magit, they aren't even notable features!
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.
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.
For reference, a full checkout of the linux kernel is 2.5GB.
It's an old long SVN repository with a lot of files. I would like to split it in two SVN repos but that would destroy their history. Any ideas?
> I'd expect everything to be slow.
It's actually very OK with git in cygwin-bash.
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)
Now I use it literally everywhere, from the command line as a quick git workspace switcher, to all sorts of git commands in vim using fzf.vim [1].
fzf is brilliant.
But I find that lazygit does everything I want and more, better than I would have designed it!
git-fuzzy seems to also support two-column diff view which isn't in tig. Good job.
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.
aside: it's surprising that a browser requires 3GB to display 16MB of gifs. sadly, wouldn't be surprised if the same phenomenon plagues every browser.
I think this warrants a bug report for palemoon
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