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.
Not a CLI, but GitKraken does that for most commands.
Show HN: I made a tool that made me faster at Git
211–220 of 235 posts
Re: Show HN: I made a tool that made me faster at Git
#212I’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.
Re: Show HN: I made a tool that made me faster at Git
#213Earlier quoted context omitted.
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.
The problem isn't Emacs, since the core program works fine on Windows (as does vim). Many packages for both also work just fine.
But then there's that subset of packages that don't work fine. Some can be fixed with fiddling, but then you lose that Emacs thing of installing a package and be on your way (usually a point in favour of Emacs over vim I might add!). And some just can't be fixed, which leaves me either using a different editor for those needs or just not using those packages by using conditional configs.
However then we run into a little peeve of mine: the reason I want to use a tool like vim or Emacs is to have the same tool working the same way everywhere. I don't want to learn and more importantly maintain two setups. I want to sync my one setup across any machine I use and have it work the same way. I also don't want to have the situation that my editor works one way on system A and another on system B.
Re: Show HN: I made a tool that made me faster at Git
#214Earlier quoted context omitted.
> I think that's why VSCode has gained so much traction. For coding it's got easily 90% of the same features as both vim and Emacs Is that a joke? How can you possibly know this if you haven't used emacs for a start. Do you really think it has 90% of the features of a 35 year old project? If emacs is difficult to set up on Windows you should stop using it. The awesome stuff you hear about is mostly the result of usin…
I have used vim for god knows who long, and I've tried Emacs several times for a few months at a time before giving up. So I do think that for coding VSCode absolutely has 90% of the features that both vim and emacs offer. Note how I said "for coding"? That's not an accidental or trivial part of my comment. For writing and managing code the feature-sets are on par in all three for sure and if you disagree then I am g…
> 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.
Re: Show HN: I made a tool that made me faster at Git
#215Earlier quoted context omitted.
>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…
How did you get magit to not be slow as hell on Windows? It’s brutally slow on my windows box and lightning quick on my Mac.
>How did you get magit to not be slow as hell on Windows?
By using mercurial :-)
Had no idea magit is slow on Windows. Any idea why?
Re: Show HN: I made a tool that made me faster at Git
#216Earlier quoted context omitted.
I have used vim for god knows who long, and I've tried Emacs several times for a few months at a time before giving up. So I do think that for coding VSCode absolutely has 90% of the features that both vim and emacs offer. Note how I said "for coding"? That's not an accidental or trivial part of my comment. For writing and managing code the feature-sets are on par in all three for sure and if you disagree then I am g…
> 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.
Re: Show HN: I made a tool that made me faster at Git
#217Earlier 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. I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Git is only tangentially related to file editing, so it doesn't really make sense for an editor to know anything specifically about it. > Every time I hear people saying…
> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?
That's similar to saying "a smart phone is a smartphone" why not have one device to take calls, and another to store contacts, another to browse the web, another to listen to music. It's ergonomics.
Many things are more efficient when integrated.
Re: Show HN: I made a tool that made me faster at Git
#218Earlier quoted context omitted.
How did you get magit to not be slow as hell on Windows? It’s brutally slow on my windows box and lightning quick on my Mac.
>How did you get magit to not be slow as hell on Windows? By using mercurial :-) Had no idea magit is slow on Windows. Any idea why?
It’s mainly due to the cost of spinning up subproccesses and certain FS operations on Windows. Magit spins up a bunch of git processes for certain operations and can be quite slow due to it. Look into fscache settings for a speedup
Re: Show HN: I made a tool that made me faster at Git
#219Whether or not anyone is tired of typing git commands this is a cool project. I intend to try it out. Great work jesseduffield!
Re: Show HN: I made a tool that made me faster at Git
#220If 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 ther…
You can specify the commit to look back from on the command line for blame. See [1]
> Optionally, start annotating from the given revision.