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

141–150 of 235 posts

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

#141

Post by dmortin »

john2x wrote: post #133
yellowapple wrote: post #126

Earlier quoted context omitted.

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).

I think it's good to keep doing some things via command line, so as not to forget how Git works "under the hood". I also keep my Git alias commands to a minimum for a similar reason.

For me flow is important, so that I don't get distracted when working. The best way to achieve this is having single key shortcuts.

Knowing how GIT works uder the hood is less important than staying in the flow, at least for me as a developer. People responsible for repository maintenance may have other priorities.

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

#142

Post by h1d »

was_boring wrote: post #33

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.

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.

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

#144

Post by kccqzy »

a-b wrote: post #138

But why? There are so many awesome tools like tig and magit! - https://github.com/jonas/tig - https://magit.vc/

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.

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

#145

Post by h1d »

gear54rus wrote: post #101
webrender wrote: post #50

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

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.

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.

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

#146

Post by DoofusOfDeath »

roryisok wrote: post #99
mlthoughts2018 wrote: post #49

Earlier quoted context omitted.

I personally prefer to use a combination of a foot pedal and eye tracking cameras to enter a Reed-Solomon code of taps and blinks uniquely mapping to git commands.

I think I've met you at a conference. Were you the guy blinking U-S-E-V-I-M on Morse code during conversations

I'm guessing people just ignored it because he was in Insert mode the whole time.

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

#147

Post by jolmg »

hv42 wrote: post #130
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 comm…

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

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

#148

Post by akula1001 »

frenchie14 wrote: post #80
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…

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 :)

This is why I advocate against aliases. History is universal, more powerful and needs zero configuration. ^r and few keys takes me to any command part of my daily repertoire. It really shines as the commands get more and more verbose.

^rstat -> git status

^rcomm -> git commit

^rkout -> git checkout -d foo

^redit -> git commit --amend --no-edit

^rdeco -> git commit --oneline --decorate

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

#149

Post by imdsm »

jolmg wrote: post #147
hv42 wrote: post #130

Earlier quoted context omitted.

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

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

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

I agree with this. Strongly.

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

#150

Post by dvlsg »

yyx wrote: post #91
corndoge wrote: post #26

Earlier quoted context omitted.

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

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

I think naming the branch and/or the pr title after the jira ticket works too. I think it just needs to contain it, too. My feature branches usually look something like feature/proj-123-short-description. But to be honest, my extended commit descriptions usually contain the ticket number too, so I may be remembering wrong.

Not sure if that's better or worse, though.

Post reply on HN