
Show HN: I made a tool that made me faster at Git - jesseduffield
https://github.com/jesseduffield/lazygit
======
jolmg
> are YOU tired of typing every git command directly into the terminal

I'm not. Are there many people that are? Is this not just a matter of learning
to use shell keybindings effectively? That and aliases does wonders to avoid
repetitive typing. Many times I type `git s` (alias for `git status -s`) out
of reflex when I really meant to do `ls`.

When I forget to add `-a` to `git ci -m ...` (`ci` being `commit`) and get an
error because the index is empty, I just `<caps>kF-aa<enter>` (<caps> being
<esc>) to add it and re-execute. It's muscle memory; I do it before I even
realize I did it.

~~~
hv42
If you editor has a correct git support, you never need to do git status
because it will show you which files had been edited since the last commit.

Every time I hear people saying how much they prefer the git command line is
because they never seriously tried to leverage the git features of their IDE.

Vs code with git lens or intellij idea have excellent git integration.
Everything is one shortcut away. The git commands that are used are log into a
console if you want to check.

At the end of the day both methods work, it's just a matter of preference but
it is worth trying a good git UI.

Also if you ever try to teach someone git, it's not as intuitive as you think
[1]. Having a consistent UX can help.

That's why there is definitely a space for this kind of git UI as presented in
the article. [1][http://stevelosh.com/blog/2013/04/git-
koans/](http://stevelosh.com/blog/2013/04/git-koans/)

~~~
jolmg
> If you editor has a correct git support, you never need to do git status
> because it will show you which files had been edited since the last commit.

I prefer sticking to the Unix way. An editor is an editor. Why should it
support git specifically? Git is only tangentially related to file editing, so
it doesn't really make sense for an editor to know anything specifically about
it.

> Every time I hear people saying how much they prefer the git command line is
> because they never seriously tried to leverage the git features of their
> IDE.

But I am! The whole OS is my IDE.

Seriously though, I've done fugitive in vim and magit in emacs. After some
time of using them almost exclusively, I've decided it's better to use the
shell. It's not because I haven't tried more "integrated" ways of programming,
but because I find that the flexibility/power that comes with treating every
feature of an IDE as a separate program in an OS environment is better.

EDIT: Added more comments.

~~~
int_19h
> I prefer sticking to the Unix way. An editor is an editor. Why should it
> support git specifically?

Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs
should support Git.

------
pandler
Awesome work OP! I’m a big fan of using tools like this to supplement git,
especially when it comes to some of the more complex operations.

Personally I use tig, which is basically this but different. I used to use
Sourcetree and I loved it but it slowed to a crawl with bigger projects with
long histories.

[https://github.com/jonas/tig](https://github.com/jonas/tig)

Best screenshots I can find on google are ironically from the Atlassian blog:

[https://www.atlassian.com/blog/git/git-
tig](https://www.atlassian.com/blog/git/git-tig)

~~~
weitzj
I use tig as well but I am currently experimenting with FZF and some gitconfig
aliases.

------
nickbarnwell
If you're an emacs user, I can't recommend magit [1] enough. I was a diehard
CLI user and had flags and aliases out the wazoo, and it was still a step
change in usabilty and power for me. Staging hunks, rebasing, and stashing are
all vastly easier. Amending or editing a commit is a breeze, and it's tied in
to all of the other emacs tools you already use, e.g. org-mode to boot!

It's easier to see it in action than explain it. If you've two minutes to
spare, check out this emacsrocks screencast [2], or Howard Abram's longer
presentation from the PDX Emacs Hackers meetup [3].

[1]: [https://magit.vc/](https://magit.vc/)

[2]:
[https://www.youtube.com/watch?v=rzQEIRRJ2T0](https://www.youtube.com/watch?v=rzQEIRRJ2T0)

[3]:
[https://www.youtube.com/watch?v=vQO7F2Q9DwA](https://www.youtube.com/watch?v=vQO7F2Q9DwA)

~~~
nkantar
Seeing a former coworker use Magit in Emacs is what got me to look into the
Vim version:
[https://github.com/jreybert/vimagit](https://github.com/jreybert/vimagit)

From what I gather it's nowhere near as feature-complete, but it lets me
create commits with immense ease and precision.

~~~
tambourine_man
Fugitive is great:

[https://github.com/tpope/vim-fugitive](https://github.com/tpope/vim-fugitive)

------
austenallred
> are YOU tired of typing every git command directly into the terminal, but
> you're too stubborn to use Sourcetree because you'll never forgive Atlassian
> for making Jira? This is the app for you!

lol

~~~
nvr219
this readme really speaks to me

~~~
bmer
I'm out of the loop. What's the story here? Why are devs sad about Atlassian
and Jira?

~~~
corndoge
Jira has some asinine design issues, e.g. the only way you can link a git
commit to a ticket is by putting the ticket ID into the commit message,
generally has confusing choices for UI, code blocks {code}are annoying to
add{code} and don't follow any existing conventions, integration with
Confluence sucks, basic functionality is locked away in paid extensions, the
list goes on

~~~
gonzo41
MVP Jira just needs to present a list of stuff to do. But now it's used like a
panopticon of social control where I work. And I'm thinking I'm not the only
one with stuff like Scaled Agile being out there.

~~~
_jal
Jira doesn't _have_ to be evil. It is intrinsically awful due to that tendency
enterprise database products have of growing the flexibility to reimplement
various wheels inside of them, poorly. But using it for evil depends on
managerial intent.

At my gig, everyone grumbles about Jira, because it sucks; see above. But, we
have workflows built primarily around it with various integrations, and it
works for coordinating ~200 folks in a starting-to-get-there "Agile" model.

It is actually the worst for the managers - they spend a surprising amount of
time noodling around in Jira to feed the workflows. For individual
contributors, it works and isn't too much overhead.

From an administration standpoint, it is OK (we run the on-prem version). More
stable than some enterprise monstrosities, but the with occasional problem.
The plugin-store-thing is annoying - somehow it manages to entice nearly every
new business-side user into asking for some random thing, they usually get
what they want, and then they sit unused aside from occasionally breaking
things.

~~~
swozey
> More stable than some enterprise monstrosities

It must have gotten a lot of stability improvements since I stopped managing
jira clusters a few years ago because, from the ops side of things, JIRA was
one of our main "make a cron job that restarts tomcat every night" running
jokes at multiple companies over the last decade.

I've also had wonderful (/s) experience with the unicorns in Gitlab but that's
another tale.

~~~
Aeolun
That's what you get for putting unicorns in a product.

------
pjc50
You know what would make me faster at git?

"git undo" : undo the last git command line, whatever it did. Especially if
you don't understand what it did or it overwrote local files.

~~~
lgas
[https://github.com/tj/git-extras](https://github.com/tj/git-extras) provides
"git undo" (among others).

~~~
jwilk
It's a pretty useless wrapper over "git reset":

[https://github.com/tj/git-extras/blob/master/bin/git-
undo](https://github.com/tj/git-extras/blob/master/bin/git-undo)

It won't help you if you don't understand what the last command did or when it
overwrote local files; it'll just make everything worse.

------
jesseduffield
Hey guys thanks for all the feedback so far! I whipped up a quick tutorial for
anybody who wants to know the basics
[https://www.youtube.com/watch?v=VDXvbHZYeKY](https://www.youtube.com/watch?v=VDXvbHZYeKY)

------
karmakaze
This looks great. For some reason I don't mind using the GUI tools to view
history and branches but for commits always use the command line. This should
save some time and much typing.

~~~
mehrdadn
I use TortoiseGit's GUI for everything except features that it doesn't have,
like git add -p. It makes life so much easier when you can just right-click
and go to "Show Log", search for something you care about, then right-click
that one commit in 2017 that messed things up and click "Browse repository" to
look at the entire repo & diff arbitrary files without checking out a single
file messing up your work tree. Trying to do every single thing with a command
line interface just sounds insane to me.

------
andrewshadura
I'm mostly using plain Git, but there's one thing for which I needed a TUI:
line-by-line selective committing.

After trying to find something I liked, I ended up porting crecord extension
for Mercurial to Git: [https://github.com/andrewshadura/git-
crecord](https://github.com/andrewshadura/git-crecord)

~~~
michaelmcmillan
git add --interactive?

~~~
andrewshadura
That doesn't have line-by-line functionality, and it's not interactive.

If you had a look you'd see git add -i is not even close to it ;)

------
kbumsik
I use VS Code and GitLens lately. VSCode’s diff view and GitLens explorer
cover my needs very well.

~~~
swozey
Gitlens is incredible. I can't believe none of my coworkers I ever mention it
to have used it.

~~~
sv123
The CodeLens feature in VS2017 is really similar, it's the only reason we pay
for the pro license instead of just using community edition.

~~~
h1d
It's hard to believe MS still charges people who are making their platform
more worthy and with competition from Jetbrains.

------
stockkid
Personally I have been typing all git commands manually into the terminal and
never felt a need for GUIs or tools such as this.

There are a number of git shortcuts defined in my zsh aliases [0]. It goes
like:

    
    
      # Git aliases
      alias g='git'
      alias ga='git add'
      alias ghb='git browse' # hub
      alias ghpr='git pull-request' # hub
      alias gp='git push'
      alias gpoh='git push origin HEAD'
      ...
    
    

Using these aliases, we rarely have to type more than 3-4 characters for a git
command. Savings and efficiency not only add up over years of using git, but
also accelerate as you become more proficient in using your own aliases that
fit your special needs.

[0] -
[https://github.com/sungwoncho/dotfiles/blob/master/zsh/alias...](https://github.com/sungwoncho/dotfiles/blob/master/zsh/aliases.zsh)

~~~
jordigh
With Mercurial, I like that all commands can be abbreviated to their shortest
unique prefix, plus some built-in aliases. So I type a lot of `hg up`, `hg
pus`, `hg ci`, `hg pul`, `hg bo`, and so forth. Most of these are almost the
same length as your aliases.

Whenever I have to touch git and `git co` doesn't work, I think, okay, fine,
we'll go through the full dress rehearsal; `git checkout` it is.

~~~
muxator
Plus, actually sane command names, and super powerful functionalities (for
example, answering to another comment, you always could "hg blame (annotate)"
an arbitrary version of a file without having to check it out first)!

------
a-b
But why? There are so many awesome tools like tig and magit!

\- [https://github.com/jonas/tig](https://github.com/jonas/tig)

\- [https://magit.vc/](https://magit.vc/)

~~~
kccqzy
Magit is great but it's just so incredibly slow at big repos. For certain
things like Instant Fixup magit is still faster than the command line but most
of the time I can do it much faster via the command line. Sometimes I'm not
even sure whether magit is just slow or my emacs hangs.

~~~
Pimpus
Please post your OS and Emacs version.

Magit hasnt been slow for me since I upgraded to Emacs 26. Older versions of
Emacs were not optimized for spawning processes on OSX and it was causing a
10x slowdown for some operations.

~~~
kccqzy
Perhaps I should revise my statement. It isn't magit itself that's slow, but
rather magit is calling out to slow git commands. And while those git commands
are taking up 100% of my CPU, Emacs itself is using 0% CPU and totally
unresponsive.

Just a few moments ago I had to kill Emacs because magit was executing this
command:

    
    
        git branch --remote --contains 10a1663bf96f

~~~
tarsius
That particular issue has been fixed a few weeks ago. You should update Magit.
Also you should be able to avoid killing Emacs by just pressing C-g a few
times if some subprocess takes a long time.

------
was_boring
Thanks for making this, it looks great! I'll be giving it a shot tomorrow.

I've been moving more and more to terminal for all of my development. My dev.
stack is now: vim; tmux; lynx; ddgr; zsh; and docker. It is game changing for
distraction-free programming, consistency between languages, and the ability
to use the exact same setup everywhere -- even on remote machines.

~~~
h1d
We need CLI to work on repo on remote servers. I was using tig but didn't like
it for lack of ability to easily navigating file tree on each commit and this
seems better.

------
webrender
I've been using Fork: [https://git-fork.com/](https://git-fork.com/) because
of its 2 primary advantages over SourceTree: • Dark mode • Tabs

~~~
gear54rus
Looks neat but no Linux version again :( There are 2 things I miss the most
when developing under Linux and they are Sharex and Sourcetree. Smartgit is
alright but not as good as the latter.

~~~
h1d
OT but considering Jetbrains stuff works on Linux there isn't much to miss
except a decent git GUI but do you miss anything else? I just don't find the
benefit of using Linux for development.

~~~
gear54rus
Ability to use proper shell (and env) for dev tasks and build scripts is the
main benefit for me.

Sharex is the other thing I mentioned, its screenshots/screenrecords on
steroids, check it out.

------
msinghai
I have been using
[https://github.com/scmbreeze/scm_breeze](https://github.com/scmbreeze/scm_breeze),
and though not as feature-packed, it does make the workflow fast.

~~~
mtrpcic
I've been using this for probably 6-7 years now and it's become a standard
part of my workflow. I've never had problems using git, but scm_breeze makes
things faster (shorthand commands for common operations), and adds some nice
bells and whistles. It's never caused a problem for me in the entire time I've
used it either.

------
danpalmer
I’ve yet to find a git setup that is more productive (for me at least) than
SublimeGit for Sublime Text. The combination of a text based interface with
single character shortcuts, and the quick support for staging individual parts
of files, means I’m probably twice as fast as the next best thing. It’s the
reason I haven’t moved from Sublime to VS Code.

This looks like it could be close, and I’ll definitely give it a try. If I
could decouple myself a bit more from Sublime that would be great. The plugin
community just isn’t the same as VS Code.

~~~
lttlrck
I switched to gitsavvy a few weeks back because it is more complete than
sublimegit. I paid for sublimegit years ago and really love it.

But I wanted single line commits so gave gitsavvy a go. I had to redefine a
couple of shortcuts (Ctrl-D from Discard to diff) but it’s been excellent. The
only thing I can’t get working is gitlab integration.

It’s a worth a shot.

~~~
danpalmer
Oh nice, thanks! Sublime Git has everything I need for my git workflow so I'm
not feeling like I need anything else, but I will give this a shot to see if
it's faster for the bits I do use.

------
cpeth
One Git UI that I absolutely love but I rarely see mentioned is GitKraken.
It's so nice having a fully cross-platform Git GUI, that's attractive and
intuitive.

~~~
spacesarebetter
To be honest, they try to compete with souretree and git tower but they are
there is a huge difference in the performance since GitKraken is made on
electron and really slow when looking at large diffs.

I am a long time git tower user, and i have given GitKraken more than a few
shots. I always go back to a hybrid command line and git tower workflow

------
mehrdadn
'Go' question that came up when I tried to build this: How do you build a Go
.EXE on Windows that doesn't have any file paths embedded in it?

~~~
mappu

        go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH
    

[https://stackoverflow.com/a/45302415](https://stackoverflow.com/a/45302415)

~~~
mehrdadn
Did you try this yourself? Because I already tried it and it didn't work.
Remember I said I'm on Windows.

~~~
mappu
Yes, we do this for our release builds, including Windows. It does only remove
the leading prefix (GOPATH) from panics, not the full file path.

I don't think there's a way to remove the whole file paths other than
replacing strings in the compiled binary. In our case GOPATH was the only
sensitive part (since function names can't be removed either, for reflection
to work).

We also couple it with a defer handler to obfuscate panic traces.

~~~
mehrdadn
It didn't even remove the leading prefix for me. I tried both forward and
backward slashes. (The version in the binary is with forward slashes.) Note
that I'm using go1.10.3.windows-amd64.zip.

EDIT: Looking more carefully, it seems like it actually removes the prefix for
files in the current module, but nothing from files in its dependencies. This
is despite the fact that both of them share a prefix for me, and that's what
I'm trying to remove. Any idea why?

~~~
mappu
This changed from 1.9 -> 1.10, now the asm/gc/ldflags only apply to the module
being compiled directly, not other modules.

[https://golang.org/doc/go1.10#build](https://golang.org/doc/go1.10#build)

You can resolve this by using "all" as the pattern
(-gcflags=all=-trimpath=$GOPATH)

~~~
mehrdadn
Ahh!! Okay thanks, that works... almost. Now there's still one spot left where
the path of the Go installation is embedded... :\

------
kchoudhu
How much time do people spend messing with their source control that extreme
tools like this become necessary?

I commit like, once a day. What am I doing wrong?

~~~
jolmg
To each his own, but I'd say committing once a day. That's unless I'm wrong in
thinking that doing so means your commits are quite big and could be broken up
into smaller, more manageable changes.

Personally, I like it when `git diff` displays only one or at most three
screenfuls of changes that haven't been committed.

~~~
kchoudhu
Maybe I'm one of those low productivity types that interview processes are
trying to permanently weed out, but I rarely write more than 40-50 good lines
of code per day. Commits any smaller than that would just look like code
Hemingway.

------
tootie
IntelliJ now and forever. We still have some crap on SVN and the version
control menus are nearly identical switching between that and git.

------
nvahalik
This looks super neat. Will try it out. Although I’m a sourcetree user...
lately `git add -i` has changed how I use got massively.

~~~
grimgrin
got add -p is pretty nice too

then got commit -v to verify the hunks

~~~
nvahalik
Dang. So git add -p basically just skips straight to the patch portion and
then -v adds a diff to the bottom of the commit message file so you can review
it. Nice!

~~~
greenhatman
It doesn't seem to pick up new files.

~~~
rasapetter
It can, if you first do: git add --intent-to-add <filename>

~~~
andrewshadura
Try git-crecord, you won't miss git add -p.

------
tomxor
Nice idea - I don't like going too far above the git cli, but I usually find
myself building a set of terminals watching different git commands such as
status, log, diff etc for a more parallel overview...

This tool looks like it does that a bit better with interactivity maintained,
and for some reason i'm more comfortable accepting a CLI git UI into my
workflow than a GUI.

------
idiomatic1
I don't touch aliases. History search with fzf is much better. Same number of
keystrokes, but your actions remain clear and explicit.

~~~
h1d
Do you type Ctrl-r every time issuing git command?

~~~
idiomatic1
Normally I'm using vim-fugitive, actually.

------
agumonkey
raw console magit I see

~~~
agumonkey
ps: the
[https://github.com/jroimartin/gocui](https://github.com/jroimartin/gocui) ui
toolkit used here seems very very nice

if people know an equivalent outside go, please comment

~~~
gglitch
I had the same thought. I'm amazed not to have seen any commentary here on it
yet. Looks really, really nice. I looked for something comparable for Elixir
but haven't found anything comparable yet.

------
hartator
I use GitHub desktop, it’s pretty solid.

------
DelTaco
I've always been a fan of Git Town: [https://github.com/Originate/git-
town](https://github.com/Originate/git-town)

Not a UI but helps with some commands you run in a row quite often

------
robertk
Might be a good opportunity to advertise my git-send bash function / zsh plug-
in:

[http://github.com/robertzk/send.zsh](http://github.com/robertzk/send.zsh)

~~~
__blockcipher__
While we're at it:

    
    
       git_show_blame () {
       	if [ -z "$3" ]
       	then
       		printf "USAGE: git_show_blame filepath start_line_num end_line_num" && return 1
       	else
       		[ ! -z "$4" ] && printf "\\n${LPURP}[git_show_blame]${NC} Warning: extra arguments provided. Ignoring everything after the first 3\\n\\n"
       		git show $(git blame "$1" -L "$2","$3" | awk '{print $1}')
       		return $?
       	fi
       }
    

Use with recursive search `grep -Rn your_regex .` to track down the original
commit that your pesky coworker added two years ago without any corresponding
documentation for an alert that's going critical at 2am...(only slightly
exaggerating there :P)

------
tylerjwilk00
Whether or not anyone is tired of typing git commands this is a cool project.
I intend to try it out. Great work jesseduffield!

------
eagsalazar2
I used to race and coach skiing for many years. Intermediate skiers always
used to ask me what skis to buy to make them better at
[ice|powder|moguls|steeps|etc] while I and most proficient skiers used the
same boards every day in all conditions. This tool reminds me of that.

* I acknowledge that some really great skiers are geeked on their equipment and use a variety of skis. Point still stands.

~~~
pvg
What exactly is the point, other than you just calling the author
insufficiently advanced by way of some creaky analogy? One of the many things
that distinguishes programming from skiing is that it's fairly easy for people
at all levels of expertise to make their own tools. And that's what this
person did.

~~~
eagsalazar2
You are right. Sorry everyone!

------
amleszk
Looks nice but I think you need some better documentation before anyone can
use it.

------
quickthrower2
I'm a Windows user, and I love Tortoise Git for this kind of stuff.

------
jags-v
Nice first project with go. the project made wanna learn go :).

------
anandaverma18
This utility is nice. Let me try out and save some time.

------
antjanus
Damn, that's a really nice UI!

------
thr0000waay
congrats, you have discovered darcs.

------
IshKebab
Why not just use an actual GUI then rather than a shitty TUI?

GitX (Mac only sadly) is the best of the free ones, and Tower is then best of
the commercial ones. Try those.

------
sAbakumoff
>>but you're too stubborn to use Sourcetree because you'll never forgive
Atlassian for making Jira? This is the app for you!

This is the most ridiculous ad ever.

