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

221–230 of 235 posts

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

#221

Post by bestCauliflower »

reassembled wrote: post #53
gonzo41 wrote: 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.

My previous QA manager tried to get the QA/engineering/product management groups to "do agile", heavily because of the agile board functionality added to JIRA. Nobody ever got any training on how to "do agile" but the fact that we were becoming an "agile company" was heavily pushed as the internal narrative, all the way up to execs. Most of product teams still don't function with any kind of actual agile process. Man…

In my company they outright refused to pay for a test case management solution, so we are using this free plugin for Jira: https://marketplace.atlassian.com/apps/1214038/qaspace-test-...

It works alright.

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

#222

Post by eagsalazar2 »

pvg wrote: post #114
eagsalazar2 wrote: post #43

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.

You are right. Sorry everyone!

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

#223

Post by mappu »

mehrdadn wrote: post #95
mappu wrote: post #83

Earlier quoted context omitted.

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

This changed from 1.9 -> 1.10, now the asm/gc/ldflags only apply to the module being compiled directly, not other modules.

https://golang.org/doc/go1.10#build

You can resolve this by using "all" as the pattern (-gcflags=all=-trimpath=$GOPATH)

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

#224

Post by mehrdadn »

mappu wrote: post #223
mehrdadn wrote: post #95

Earlier quoted context omitted.

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

This changed from 1.9 -> 1.10, now the asm/gc/ldflags only apply to the module being compiled directly, not other modules. https://golang.org/doc/go1.10#build You can resolve this by using "all" as the pattern (-gcflags=all=-trimpath=$GOPATH)

Ahh!! Okay thanks, that works... almost. Now there's still one spot left where the path of the Go installation is embedded... :\

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

#225

Post by vickychijwani »

nickbarnwell wrote: post #41

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…

Magit has a PR problem: most people think they need to be already using Emacs to use Magit, but that's far from the case. Indeed most Magit keybindings are single-letter like vim. I wish I could get more people to try Magit without being turned off by the fact that it's an "Emacs plugin". Hmm.. what if there were a standalone version of Magit? Would more people use it?

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

#226

Post by grimgrin »

grimgrin wrote: post #32
nvahalik wrote: post #7

This looks super neat. Will try it out. Although I’m a sourcetree user... lately `git add -i` has changed how I use got massively.

got add -p is pretty nice too then got commit -v to verify the hunks

it should be clear i was too out of it to not notice s/got/git

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

#227

Post by kccqzy »

Pimpus wrote: post #208
kccqzy wrote: post #144

Earlier quoted context omitted.

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.

I'm using the latest version of both.

Actually magit is quite fine for small personal projects. It's just that it absolutely chokes on a large monorepo I'm working on.

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

#228

Post by cup-of-tea »

kungtotte wrote: post #216
cup-of-tea wrote: post #214

Earlier quoted context omitted.

> a single application that has had 35 years to get its shit together simply won't work well? It's because the people that like emacs don't like Windows. You would see why if you would try something else. If you want emacs to work well on Windows, do it yourself. Nobody owes you anything.

Nobody owes me, and I'm not asking for anything. I'm just lamenting the fact that things are the way they are. I use both Windows and Linux, which is precisely why I want to use an editor that's properly cross-platform instead of using separate editors or use one that's configured differently based on platform. Maybe you should try Windows? It sounds like you could benefit from broadening your horizons a little bit.

I used Windows full time until ten years ago. Like many it was my first introduction to computers. I switched to Linux and never looked back even once. I've had to use Windows at work for the last 9 months and it's been an awful experience the whole time. Nothing has changed.

If there was no option for a free operating system I would stop using computers in an instant. I won't go back. Ever.

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

#229

Post by kchoudhu »

jolmg wrote: post #81
kchoudhu wrote: post #77

How much time do people spend messing with their source control that extreme tools like this become necessary? I commit like, once a day. What am I doing wrong?

To each his own, but I'd say committing once a day. That's unless I'm wrong in thinking that doing so means your commits are quite big and could be broken up into smaller, more manageable changes. Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.

Maybe I'm one of those low productivity types that interview processes are trying to permanently weed out, but I rarely write more than 40-50 good lines of code per day. Commits any smaller than that would just look like code Hemingway.

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

#230

Post by danpalmer »

lttlrck wrote: post #212
danpalmer wrote: post #173

I’ve yet to find a git setup that is more productive (for me at least) than SublimeGit for Sublime Text. The combination of a text based interface with single character shortcuts, and the quick support for staging individual parts of files, means I’m probably twice as fast as the next best thing. It’s the reason I haven’t moved from Sublime to VS Code. This looks like it could be close, and I’ll definitely give it a…

I switched to gitsavvy a few weeks back because it is more complete than sublimegit. I paid for sublimegit years ago and really love it. But I wanted single line commits so gave gitsavvy a go. I had to redefine a couple of shortcuts (Ctrl-D from Discard to diff) but it’s been excellent. The only thing I can’t get working is gitlab integration. It’s a worth a shot.

Oh nice, thanks! Sublime Git has everything I need for my git workflow so I'm not feeling like I need anything else, but I will give this a shot to see if it's faster for the bits I do use.
Post reply on HN