Live data from Hacker News

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

github.com

111–120 of 235 posts

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

#111

Earlier quoted context omitted.

Do you view that as in any way acceptable for a UI? All of these things are ultra-common operations. If Outlook were written this way, you'd have to type git inbox --full-conversation -next to read an email, and read it in less .

> Do you view that as in any way acceptable for a UI? The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems. I think most people would like a simple graphical UI, but no one has been able to create one that has the same power as the textual one. This is akin to the reason people don…

> The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems.

Is this meant to be ironic? Everything is literally the opposite of what you said. The entire reason why people make programs like the one you see here is literally that git sucks as a console program, making tasks that are inherently simple (and demonstrably so with a GUI like TortoiseGit) much harder on the command line.

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

#113

Earlier quoted context omitted.

The videos touch upon a fraction of magit’s capabilities; if nothing else, it’s a far more mature project. But the real power is integration with the rest of emacs/being written in elisp. If I want to change or script behaviour, I have easy access to all the internals, and I can integrate it with other parts of my emacs workflow. For example, I can use magit to view the diff of a coworker’s PR, easily capture snippet…

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

Just change your OS?

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

#114

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.

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.

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

#115
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'm also not tired of typing git commands. It seems almost natural now. With that said, this individual spent their free time to create something using their skills which they perceived to be an improvement/optimization upon their skill-set and shared it with the world. IMHO, that's commendable.

It definitely is. I didn't mean to sound dismissive of his work, but I can see how it does. My intent was rather to inform those who haven't realized, OP seemingly included, that the shell can be very efficient to work with. I can't see myself using this tool and being more productive than I already am with the shell, but I can still appreciate the effort and generosity in making it available to the world.

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

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

Phil Haack has a nice set of aliases that I've grown reliant on: https://haacked.com/archive/2014/07/28/github-flow-aliases/

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

#117

Earlier quoted context omitted.

The videos touch upon a fraction of magit’s capabilities; if nothing else, it’s a far more mature project. But the real power is integration with the rest of emacs/being written in elisp. If I want to change or script behaviour, I have easy access to all the internals, and I can integrate it with other parts of my emacs workflow. For example, I can use magit to view the diff of a coworker’s PR, easily capture snippet…

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 GNU tools like grep). I may have been using an unofficial port - sorry but I don't remember the link.

My Windows Emacs is almost identical to my Linux Emacs. You wouldn't know you're not in Linux. That, for me, is the joy of Emacs - it behaves the same on both OS's.

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

#118

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

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)

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

#119
post #85

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

Seeing a former coworker use Magit in Emacs is what got me to look into the Vim version: 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.

I was a die-hard vim+tmux user before switching to Spacemacs.

Now I have all the power of vim’s modal editing with Emacs’ vastly superior ecosystem of packages.

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

#120
post #91

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?

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.

Post reply on HN