Live data from Hacker News

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

github.com

191–200 of 235 posts

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

#191
post #155

Earlier quoted context omitted.

> 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. That sounds like limiting the functionality of the whole computer to what the text editor can do. That doesn't make sense. Next, you'll want to browse the web from the editor because you don't want to leave it (just because emacs does it does…

> Next, you'll want to browse the web from the editor Well, you're clearly replying to an emacs user. He/she will not find that statement the least hyperbolic.

I do. I use a separate browser. There are people who want to do everything from their editors. There are people who want to do only editing in the editor.

And there are middle ground people like me who want editor integration when it makes me more efficient (like invoking frequent VC commands right from the editor), but I do mail and browsing and stuff with external tools.

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

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

I use TextExpander (I wish there was something comparable on Linux!) and I have aliases defined:

,gcm for git commit -m ""

,ga for git add -p

,gl for git lg

and similar.

That said, I rarely use the terminal for git these days, Magit is just so much better.

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

#193

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

git add --interactive?

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

#194

Earlier quoted context omitted.

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!

It doesn't seem to pick up new files.

It can, if you first do: git add --intent-to-add

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

#195

Earlier quoted context omitted.

In my experience of using git integration features in IntelliJ, they are nice for simple tasks like quickly checking the status of a file or committing all the changes, but as soon as I need to do more complex tasks in git, I find the UIs either get in the way and slow me down or just aren’t fully featured enough to do what I need to do and I end up back on the command line. Hence why I always encourage newcomers to…

Git integration in IntelliJ is terrible IMO. It conflates staging and committing, and unstaging with reverting. I don't use it because it is a PITA, but what is even more annoying are the PR's from team members who do use it, which I have to send immediately back due to random files.

The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history.

I've never used it for anything else git related because the ui is strange.

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

#196
post #130
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.

Unless you're on someone else's machine. Then you'll still need the cli.

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

#197
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. Unless you're on someone else's machine. Then you'll still need the cli.

In that case one should stick to using vanilla git with no aliases, shortcuts, etc.

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

#198

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

My biggest complaint is the nonsensical UI. I never know when I click a ticket if I'm going to get a) a split screen view, b) a modal pop up, c) a full screen view, or d) sirens in the distance. When I click the 'back' button, I never know if I'm a) closing the ticket I have in a split screen, b) going back to the search results, or c) going back to Confluence and losing my search results and wondering how I was in C…

+1

You'd think this would mean there was a healthy market for native client apps using the JIRA API with a more pleasant UI (as there certainly is for Git, e.g.), but strangely not.

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

#199
post #143

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

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

Normally I'm using vim-fugitive, actually.

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

#200
post #130
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…

> intellij idea have excellent git integration.

I find all the colors and ques distracting while I am coding.

Post reply on HN