I've been using Fork: https://git-fork.com/ because of its 2 primary advantages over SourceTree: • Dark mode • Tabs
Show HN: I made a tool that made me faster at Git
101–110 of 235 posts
Re: Show HN: I made a tool that made me faster at Git
#102How 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?
On the day to day work, git use is simple; it’s with large major version upgrades, refactors, merging many branches together, and spiking/research where the more advanced features really shine.
Re: Show HN: I made a tool that made me faster at Git
#103Re: Show HN: I made a tool that made me faster at Git
#104> 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…
IMHO, that's commendable.
Re: Show HN: I made a tool that made me faster at Git
#105If 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.
Re: Show HN: I made a tool that made me faster at Git
#106Re: Show HN: I made a tool that made me faster at Git
#107> 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…
Re: Show HN: I made a tool that made me faster at Git
#108Not a UI but helps with some commands you run in a row quite often
Re: Show HN: I made a tool that made me faster at Git
#109Earlier quoted context omitted.
My biggest complaint is the nonsensical UI. I never know when I click a ticket if I'm going to get a) a split screen view, b) a modal pop up, c) a full screen view, or d) sirens in the distance. When I click the 'back' button, I never know if I'm a) closing the ticket I have in a split screen, b) going back to the search results, or c) going back to Confluence and losing my search results and wondering how I was in C…
Things could be worse. Nothing made me miss jira like using Rally.
Re: Show HN: I made a tool that made me faster at Git
#110Earlier quoted context omitted.
Based on those videos, lazygit looks like it does the same things as magit, but with a little more "chrome" (boxes around lists). How do the two projects compare? Could they be merged, or do they have fundamentally different philosophies?
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…
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. Plugins/modes rely on being run in *nix environments to work well, and the workarounds for Windows are never 100%. The startup times start to suffer a lot too in vim and Emacs when you pile on a lot of features.
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 (if not more), but it's trivial to set up and with many users being on Windows pretty much everything has first-class Windows support.
So that's what happens every time. I stick to VSCode and keep a lightweight vim setup around for quick text edits since it opens instantly. Perfect for quickly changing a config file or jotting something down if I don't have VSCode open.