Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I made a tool that made me faster at Git

github.com

Post reply on HN
Print view View original

121–130 of 235 posts

Re: Show HN: I made a tool that made me faster at Git

#121

Post by tcoff91 »

BeetleB wrote: post #117
kungtotte wrote: post #110

Earlier quoted context omitted.

Whenever I read a comment or blog post about Emacs I'm like "I should definitely try it out, because that sounds awesome", then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it. It's the same thing with vim for that matter. A basic-ish text editor setup is trivial in both editors but beyond that things start to fall apart.…

>then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it. The first few times I did it on Windows it was a pain (almost a decade ago). You had to install some dependencies manually. But the last few times I did it it really was a straightforward install, with everything working out of the box (except any commands that rely on…

How did you get magit to not be slow as hell on Windows?

It’s brutally slow on my windows box and lightning quick on my Mac.

Re: Show HN: I made a tool that made me faster at Git

#122

Post by kungtotte »

BeetleB wrote: post #117
kungtotte wrote: post #110

Earlier quoted context omitted.

Whenever I read a comment or blog post about Emacs I'm like "I should definitely try it out, because that sounds awesome", then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it. It's the same thing with vim for that matter. A basic-ish text editor setup is trivial in both editors but beyond that things start to fall apart.…

>then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it. The first few times I did it on Windows it was a pain (almost a decade ago). You had to install some dependencies manually. But the last few times I did it it really was a straightforward install, with everything working out of the box (except any commands that rely on…

A plain vim or Emacs is trivial to set up and is indistinguishable, simple config changes are also trivial, but once you go deeper into plugins/layers for things like fuzzy file finders it starts to fall apart because they start relying on Linux-only tools or the Windows equivalent tools aren't as good.

Some of it you can get to work after copious amounts of fiddling, but I don't have that kind of time or willpower. While it might not be as powerful the total amount of time I've spent actually making config changes in VSCode is probably about 30 minutes. This is including time waiting for extensions to download! Not to mention that it ships with many features out of the box such as git integration.

Re: Show HN: I made a tool that made me faster at Git

#123

Post by sv123 »

swozey wrote: post #75
kbumsik wrote: post #73

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

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

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.

Re: Show HN: I made a tool that made me faster at Git

#124

Post by dmortin »

jolmg wrote: post #66

> 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…

If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run.

Version control functions should be available right in your editor (e.g. magit) and you can't really beat one character hotkeys for version control stuff. It doesn't get more convenient than that.

Re: Show HN: I made a tool that made me faster at Git

#125

Post by hyperpallium »

jolmg wrote: post #66

> 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…

What is `kF-aa`?

Re: Show HN: I made a tool that made me faster at Git

#126

Post by yellowapple »

dmortin wrote: post #124
jolmg wrote: post #66

> 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…

If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run. Version control functions should be available right in your editor (e.g. magit) and you can't really beat one character hotkeys for version control stuff. It doesn't get more convenient than that.

Seconding the in-editor approach. Magit is wonderful (though I often do end up heading to the command-line for certain things out of habit).

Re: Show HN: I made a tool that made me faster at Git

#127

Post by terminalcommand »

jolmg wrote: post #82
frenchie14 wrote: post #80

Earlier quoted context omitted.

Since `git status` is my most common command I've got it aliased to just `s`. Every time I use another machine it throws me off when the command doesn't work :)

I use `s` to launch a new terminal window in the same directory as the shell that called it. This way, I launch a terminal, go to a project directory, and then type s a few times to get sufficient terminals in that context. I know it's popular, but I think I'd find it confusing for completely separate commands to relate like that. It's like cups; I was really surprised to find that the shell command `cancel` was abou…

You might want to check out tmux. I've changed my terminal to "st -c tmux" and every time I open a terminal window I get access to multiple frames, (nearly) infinite scrolling, window management and more.

Re: Show HN: I made a tool that made me faster at Git

#129

Post by corndoge »

kemayo wrote: post #120
yyx wrote: post #91

Earlier quoted context omitted.

> the only way you can link a git commit to a ticket is by putting the ticket ID into the commit message Is there any other way?

Presumably after the fact by linking them entirely within Jira. You could mention the commit in the ticket, but that wouldn't make a back-link from the commit if someone's browsing from that direction. That said, I don't really mind mentioning the ticket in the commit. It's relevant to what one is doing when one makes the commit. But then I use gerrit at my job, so I don't have room to complain about others' systems.

It sucks when you work on public open source code with internal forks.

Re: Show HN: I made a tool that made me faster at Git

#130

Post by hv42 »

jolmg wrote: post #66

> 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…

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/

Post reply on HN