Show HN: `fzf` * `Git` done right(github.com)
github.com
Show HN: `fzf` * `Git` done right
https://github.com/bigH/git-fuzzy
64 comments
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:
EDIT: formatting
For example:
Alt-E => €
Alt-U => ¨
Alt-C => ç
EDIT: formatting
I think it's nicer if it used ctrl- bindings instead.
i'll have to make this configurable in some sort of way
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.
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.
[deleted]
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.
Try `export`ing this env var:
https://github.com/bigH/dotfiles/blob/master/configs/core.sh...
In the meanwhile, I'll try to repro.
https://github.com/bigH/dotfiles/blob/master/configs/core.sh...
In the meanwhile, I'll try to repro.
Also no change, oddly.
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
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
I have 0.1.1 from homebrew.
(delta author here) Line numbers have been added to delta in a contributed PR: https://github.com/dandavison/delta/pull/190. It will merge soon and be in the next release.
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
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
This looks nice! https://jonas.github.io/tig/ is another command-line UI for Git with similar two-column layout.
git-fuzzy seems to also support two-column diff view which isn't in tig. Good job.
git-fuzzy seems to also support two-column diff view which isn't in tig. Good job.
A nice tutorial on tig, now that you mentioned it. https://www.atlassian.com/blog/git/git-tig
I really like the "git diff" example. Almost wants me to throw Git Tower after that! Nice job.
I personally love Laxygit https://github.com/jesseduffield/lazygit. It makes sure I don't have to think.
I really like the FZF approach and did some nice git integrations myself. Nothing close to this post, this is great work!
But I find that lazygit does everything I want and more, better than I would have designed it!
But I find that lazygit does everything I want and more, better than I would have designed it!
lazy git is sick!
gitin is easy to use to quickly check the state.
https://github.com/isacikgoz/gitin
https://github.com/isacikgoz/gitin
If you're an emacs user, check out https://magit.vc/
Life changing
I've always been curious about how it compares with vim + fugitive, which provides a good git/vim integration
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.
Hi. Hardcore 10+ year vim zealot here.
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 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.
Care to explain what you think is so good about it? I used emacs with evil a couple times but never understood the hype around magit
Not a heavy magit user (or git, for that matter), so I can't say. However, you may want to look on Youtube for ideas:
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.
https://github.com/jwiegley
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.
https://github.com/jwiegley
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.
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.
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.
Off topic, but have you transposed left Ctrl and caps lock? That saved me from real pain, not kidding.
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.
an alternative route (what i've been doing for the past 5 years or so) is to switch left Ctrl with left Alt. My emacs life was never the same after.
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.
Many blog posts have been written about the features of magit, so I wont attempt to enumerate them here.
Did you try vimagit? If so, what's wrong/missing with it?
https://github.com/jreybert/vimagit
https://github.com/jreybert/vimagit
Many things. It's great, but it doesn't hold a candle to magit.
The README lists out several things that are missing that not only exist in magit, they aren't even notable features!
The README lists out several things that are missing that not only exist in magit, they aren't even notable features!
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.
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.
Maybe use Windows Subsystem for Linux?
WSL1 makes filesystem operations slower. WSL2 will make it slower for the windows side
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)
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)
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.
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.
Well, let's just be honest here, a 3-4 gb git repo is ridiculously huge. I'd expect everything to be slow.
For reference, a full checkout of the linux kernel is 2.5GB.
For reference, a full checkout of the linux kernel is 2.5GB.
> a 3-4 gb git repo is ridiculously huge.
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.
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.
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.
Also if you've never used Magit over SSH via TRAMP, you don't know what magic is...
I was introduced to fzf by a co-worker about a year ago when I started working on a team that used git.
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.
1. https://github.com/junegunn/fzf.vim
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.
1. https://github.com/junegunn/fzf.vim
I've been using fzf on the command line and within NeoVim for a about a year now, and it's made my workflow a lot faster. Highly recommended.
Check out magit.
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 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.
those gifs are huge, but the author in me really wanted eye candy on those pages.
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.
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.
Use webm instead of gifs.
It takes ~120MB on Chrome. (compared to ~40MB for a different repo page on github).
I think this warrants a bug report for palemoon
I think this warrants a bug report for palemoon
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
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
@parentheses: see palemoon maintainer's response to my bug report, you may find it relevant.
"done right" is rather subjective. It would be better if mods can suggest a better title.
how about '`fzf` + `git` to melt your face'?
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 recommend you check out the log command. It’s quite powerful and the closest to a “git history search engine” I’ve ever seen.