Live data from Hacker News

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

github.com

201–210 of 235 posts

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

#202

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?

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

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

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

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

#205

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.

True, but frankly it is Git’s model that is broken, or at the very least overcomplicated.

I do not care whether files are staged or not up until the point I actually want to commit, so personally the IntelliJ way of doing it is perfect.

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

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

I used the ide interaction then moved to the terminal once I realized there are really only a subset of commands you need to know. There are visual things that are still handy that the ide does, but to perform commands, I feel like the terminal is more explicit and you know what subsequent steps you’re taking (relatively, of course).

Same with vim. Too many options. Poor UX. Eg. Why are there two way to scroll down? Just use ctrl-d which helps you retain the context of the code you’re navigating.

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

#207

Earlier quoted context omitted.

Just change your OS?

I think it kind of proves my point when the solution to not being able to set an editor up is to change your entire OS... (Also: no)

He has a point. Why complain about Emacs when the problem is Windows?

To be fair, I am known to use all three OS's from time to time. I just have conditional guards to prevent loading packages that break on Windows. Mostly everything works the same. In fact, I originally learned Emacs on Windows back when I was a younger and noobier programmer.

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

#208
post #144
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.

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.

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

#209
post #176

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.

Many operations have an --abort option during the process. In other cases, there's `git reflog`.

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

#210

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

Thank you for this. I've been missing mercurial interactive committing for a while.
Post reply on HN