Live data from Hacker News

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

github.com

91–100 of 235 posts

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

#91
post #19

Earlier quoted context omitted.

I'm out of the loop. What's the story here? Why are devs sad about Atlassian and Jira?

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?

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

#92
post #19

Earlier quoted context omitted.

I'm out of the loop. What's the story here? Why are devs sad about Atlassian and Jira?

Jira is Turing-complete. Let me repeat that. Your ticketing system is Turing-complete. I don't remember where I heard this first, but someone at my company (at least supposedly) proved it once. Jira has managed to grow into such a bloated, complex, incredibly pointless piece of software that I've never met someone who likes it. It's like software design by committee, where every manager involved had some pet project…

Can't read this thread without remembering the following nugget:

https://twitter.com/HackerNewsOnion/status/98160924222131814...

It's funny because it's true.

GitHub Issues is just so much more straightforward to use; throw Waffle on it for added functionality and your team is good!

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

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

You may want to try emacs just for magit. That is, using it as a Git GUI while using VIM for everything else (if you don't want to switch).

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

#94
post #75
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.

It really is amazing. To be able to mouseover a line of code and see who committed it, link to the commit and see what it was before... It saves so much time

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

#95
post #83

Earlier quoted context omitted.

Did you try this yourself? Because I already tried it and it didn't work. Remember I said I'm on Windows.

Yes, we do this for our release builds, including Windows. It does only remove the leading prefix (GOPATH) from panics, not the full file path. I don't think there's a way to remove the whole file paths other than replacing strings in the compiled binary. In our case GOPATH was the only sensitive part (since function names can't be removed either, for reflection to work). We also couple it with a defer handler to obf…

It didn't even remove the leading prefix for me. I tried both forward and backward slashes. (The version in the binary is with forward slashes.) Note that I'm using go1.10.3.windows-amd64.zip.

EDIT: Looking more carefully, it seems like it actually removes the prefix for files in the current module, but nothing from files in its dependencies. This is despite the fact that both of them share a prefix for me, and that's what I'm trying to remove. Any idea why?

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

#97

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…

What I like most about magit is browsing the history of a file via its git-blame mode. It shows you the file split into sections indicating what commit was responsible for that section's lines. Doing `C-x g b` on one of those sections visits the file at that commit and does git blame again without needing to `checkout` that commit. I wish I knew how to be as effective doing that with `git blame` on the shell. Is there a way to provide the commit to `git blame` without needing to `checkout`?

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

#99

Earlier quoted context omitted.

Personally I prefer to alias git to g, then setup my aliases in gitconfig. https://github.com/GitAlias/gitalias g f && g rom git fetch && git rebase origin/master You could go nuts and make it even shorter with https://github.com/thoughtbot/gitsh gitsh > f & rom

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

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

#100
post #78
post #40

Earlier quoted context omitted.

MVP Jira just needs to present a list of stuff to do. But now it's used like a panopticon of social control where I work. And I'm thinking I'm not the only one with stuff like Scaled Agile being out there.

Jira doesn't have to be evil. It is intrinsically awful due to that tendency enterprise database products have of growing the flexibility to reimplement various wheels inside of them, poorly. But using it for evil depends on managerial intent. At my gig, everyone grumbles about Jira, because it sucks; see above. But, we have workflows built primarily around it with various integrations, and it works for coordinating…

> More stable than some enterprise monstrosities

It must have gotten a lot of stability improvements since I stopped managing jira clusters a few years ago because, from the ops side of things, JIRA was one of our main "make a cron job that restarts tomcat every night" running jokes at multiple companies over the last decade.

I've also had wonderful (/s) experience with the unicorns in Gitlab but that's another tale.

Post reply on HN