Show HN: I made a tool that made me faster at Git
github.com
github.com
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 an error because the index is empty, I just `<caps>kF-aa<enter>` (<caps> being <esc>) to add it and re-execute. It's muscle memory; I do it before I even realize I did it.
I know it's popular, but I think I'd find it confusing for completely separate commands to relate like that. It's like cups; I was really surprised to find that the shell command `cancel` was about print jobs. I'd thought it be something more generic. I like it that git keeps all these functions related as subcommands. Makes things more readable. `git status` is not general system status, it's git's status.
As to infinite scrolling and window management, I prefer to set the scrollback buffer length on my terminal (urxvt) to a ridiculously large number, and use a real window manager (i3 for me). It's kind of weird how so many applications have their own specific window manager inside them, like tmux (windows and tabs) or text editors (vim and emacs windows and tabs) or browsers (firefox and chromium tabs) or file managers (dolphin and pcmanfm tabs) or spreadsheets (sheets). i3 allows me to tile, tab, or stack any windows I want in any arrangement with a single set of keybindings (as opposed to the differing keybindings of each application).
Anyway, another thing that's cool about tmux is copy mode. It's awesome to execute a command, hit a key to be able to move the cursor throughout the whole buffer, and copy some piece of the output any command you've executed there, to then paste in a new command. I found that urxvt has an extension that allows the same thing, and it uses the system clipboard! So, I can not only use what I copy for a new command, I can use it elsewhere like copying a url and pasting it on a web browser using only the keyboard. It's also useful to do searches in the output of commands I've executed. So, if run a command that produces a lot of output and I want to know if it outputted something in particular, but I don't want to rerun it to pipe to less or grep or I know that it's not going to result in the same output, I can just hit a key, type what I want to search and see if it finds it.
'y' (yank) = git pull
's' (shove) = git push
'g' (give) = git commit -am x
'o' (open) = git checkout x
'p' (pick up) = git branch x
'l' (look at) = git status
^rstat -> git status
^rcomm -> git commit
^rkout -> git checkout -d foo
^redit -> git commit --amend --no-edit
^rdeco -> git commit --oneline --decorate
IMHO, that's commendable.
I use aliases too but I also use SourceTree (gasp) for bigger commits. It's not even that I don't know how to git add -p, but clicking "add this hunk" is way easier to do.
Well, it's not like I did something unique. The aliases feature of git is precisely to make commonly used commands shorter, so I found it odd that OP would make a whole new git front-end, apparently to solve the same problem. That's why I asked, "Are there many people that are?", because I wanted to know if many others also found the shell insufficiently efficient and maybe discuss that.
I didn't mean to rain on his parade, but I can see that he might not have expected his post's discussion to mostly be about CLI vs GUI or integrating git with editors vs not. I honestly did not expect this much discussion to come out of my comment, either. Then again, how a discussion develops within a community is not really in any individual's control.
Version control functions should be available right in your editor (e.g. magit) and you can't really beat one character hotkeys for version control stuff. It doesn't get more convenient than that.
Knowing how GIT works uder the hood is less important than staying in the flow, at least for me as a developer. People responsible for repository maintenance may have other priorities.
That sounds like limiting the functionality of the whole computer to what the text editor can do. That doesn't make sense. Next, you'll want to browse the web from the editor because you don't want to leave it (just because emacs does it doesn't mean it isn't absurd).
Anyway, I think it's better to configure the system so using multiple programs is as quick and effortless as possible. For your example, I use i3, a tiling window manager, and have the screen split with a terminal window on the left and my editor on the right. If I wanted to check `git status`, I just type `<super+h>git s<enter>`. To go back to the editor, `<super+l>`. There's really not much difference with a single character shortcut.
Not really. It's about putting the most frequent features into your editor, so they can be accessed effortlessly. If you have to do something which is less frequent and the editor does not support it then you still have the terminal.
> If I wanted to check `git status`, I just type `<super+h>git s<enter>`. To go back to the editor, `<super+l>`. There's really not much difference with a single character shortcut.
It's efficient compared to switching to the terminal with alt-tab or something, though by single shortcut I meant that you can use it right in your editor buffer, so it's really just pressing one or two keys vs. `<super+h>git s<enter>`
Well, you're clearly replying to an emacs user. He/she will not find that statement the least hyperbolic.
And there are middle ground people like me who want editor integration when it makes me more efficient (like invoking frequent VC commands right from the editor), but I do mail and browsing and stuff with external tools.
# x| = cursor is in insert mode, after char 'x'
# |x| = cursor is in command mode, on char 'x'
# (<keys>) = keystrokes entered resulting in prompt on next line
$ git ci -m "<str>"| (<CR>)
$ | (<Esc>k) # puts shell prompt into command mode (<Esc>) and cycles upwards to previous command (k)
$ git ci -m "<str>|"| (F-) # from current position, reverse search (F) and stop on first occurence of '-'
$ git ci |-|m "<str>" (aa) # cursor is on '-' char, append (a) 'a', i.e. transition into insert mode by advancing cursor after current char, then insert 'a' literally
$ git ci -a|m "<str>" (<CR>) # execute command
$ |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 commands that are used are log into a console if you want to check.
At the end of the day both methods work, it's just a matter of preference but it is worth trying a good git UI.
Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help.
That's why there is definitely a space for this kind of git UI as presented in the article. [1]http://stevelosh.com/blog/2013/04/git-koans/
I do agree that git could certainly do with a more consistent command line interface - but I imagine that won’t even be considered until that next major version of git, if it ever arrives.
I've never used it for anything else git related because the ui is strange.
I do not care whether files are staged or not up until the point I actually want to commit, so personally the IntelliJ way of doing it is perfect.
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 how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE.
But I am! The whole OS is my IDE.
Seriously though, I've done fugitive in vim and magit in emacs. After some time of using them almost exclusively, I've decided it's better to use the shell. It's not because I haven't tried more "integrated" ways of programming, but because I find that the flexibility/power that comes with treating every feature of an IDE as a separate program in an OS environment is better.
EDIT: Added more comments.
I agree with this. Strongly.
Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs should support Git.
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.
Not as part of the same operation, but the usual workflow is that there's a pane in the somewhere that lists all modified and staged files, and you can click on those to see diffs (or just click "commit" if you don't care).
I have used IDEs but I still prefer the CLI client.
Like with most things in IT, GUIs are great for simple things but the CLI is more expressive and exposes more options. Then once you've spent enough time using the CLI tools it's sometimes more jarring to switch between the GUI and CLI than it is to just use the CLI for simple tasks that could easily be done in the GUI.
But any action I want to be made on the repository, I do it myself.
I have some exceptions though, like if I want to revert the hunk I have the cursor on it's nice to be able to revert (or even stage, but I still use `git add --patch` for that) it with one shortcut.
I think this statement is much more powerful in reverse. People who prefer the git features of their IDE have probably never seriously tried to leverage the features of git...
I prefer the git command line. It supports every single feature of git, and as an interface it’s completely and totally frictionless.
People trying to create tools and UX around git usually do so under the false impression that git is the source of friction, when really they are.
> Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help.
Are there people who need this kind of help learning, but then go on to do well at it?
I’ve found programming in general is extremely binary. Either you’re the kind of person that can grasp it and has the motivation to track down answers yourself and hack away, or you aren’t.
Being able to pick up a new system or technology and understand it very quickly is what it means to be a programmer, even more so than the act of programming itself in my opinion. I think trying to find shortcuts around that to teach people is a bit of a catch-22.
Unless you're on someone else's machine. Then you'll still need the cli.
I find all the colors and ques distracting while I am coding.
Same with vim. Too many options. Poor UX. Eg. Why are there two way to scroll down? Just use ctrl-d which helps you retain the context of the code you’re navigating.
I also had even shorter shell aliases like gl, but abandoned that. I'm switching shells to often and their configs are constantly out of sync which confuses more than it helps.
I can diagnose and fix issues for people in around 5 minutes leaving them with history that works everywhere and I don't need to jump to my workstation for reference on aliases.
Thankfully, people I work with seem to like git, except for the odd git push --force breaking branches for them.
That reminds me that I'll have to teach one QA to do rebases. His merges break our history graph in funny ways.
,gcm for git commit -m ""
,ga for git add -p
,gl for git lg
and similar.
That said, I rarely use the terminal for git these days, Magit is just so much better.
Personally I use tig, which is basically this but different. I used to use Sourcetree and I loved it but it slowed to a crawl with bigger projects with long histories.
Best screenshots I can find on google are ironically from the Atlassian blog:
It's easier to see it in action than explain it. If you've two minutes to spare, check out this emacsrocks screencast [2], or Howard Abram's longer presentation from the PDX Emacs Hackers meetup [3].
[1]: https://magit.vc/
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 snippets, including links to their location in our internal BitBucket instance, into an org buffer, and then write up and send an HTML formatted message with my comments, syntax highlighting, etc to my colleagues with my feedback.
Similarly, my TODO list is managed by org, and I can have links to commits or files at a certain commit directly in my agenda or notes and jump to them.
This is all within my editor, with all the text editing, code navigating, and linting capabilities it provides!
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.
(Also: no)
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.
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.
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.
It’s brutally slow on my windows box and lightning quick on my Mac.
By using mercurial :-)
Had no idea magit is slow on Windows. Any idea why?
Some of it you can get to work after copious amounts of fiddling, but I don't have that kind of time or willpower. While it might not be as powerful the total amount of time I've spent actually making config changes in VSCode is probably about 30 minutes. This is including time waiting for extensions to download! Not to mention that it ships with many features out of the box such as git integration.
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 using emacs on an OS that is decent for development. But if you insist on staying in your prison then you'll have to put up with what Microsoft lets you have.
I should stop using Windows because a single application is difficult to set up? Throw out my entire OS with the plethora of other applications I use because a single application that has had 35 years to get its shit together simply won't work well? That's a reasonable position for sure!
Developing on Windows works absolutely fine, and if you wan't to talk about prisons and what "Microsoft lets me have" how about we talk about the WSL? They have no reason to include it in Windows but they do. A whole bunch of Linux software became available over night in a native Windows environment because of something Microsoft did. The ones who are digging their heels in at this point are all the *nix developers who refuse to support Windows as a first-class platform, so talk about being in a prison! Your software only works well on a subset of all operating systems.
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.
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.
If there was no option for a free operating system I would stop using computers in an instant. I won't go back. Ever.
If you use it daily don't forget to donate to the developer at least once, sprinkle some of that full-time corporate cog money on them.
From what I gather it's nowhere near as feature-complete, but it lets me create commits with immense ease and precision.
Now I have all the power of vim’s modal editing with Emacs’ vastly superior ecosystem of packages.
What you should have done is use magit and looked into the emacs version of vim: https://github.com/emacs-evil/evil
> Optionally, start annotating from the given revision.
lol
Most of product teams still don't function with any kind of actual agile process. Many try to fake it by endlessly throwing all of their work into the JIRA agile boards, which constantly have sprints rolling over, and are impossible to track any kind of actual velocity with. On our team we just said screw this and went back to getting things done, and tracking things how we wanted to track them.
Don't even get me started on the nightmare that is JIRA TCM, which my company is currently still stuck with for test case management.
It works alright.
Thanks for putting this into words for me. This is exactly how I feel about Jira. Incompetent middle management automates their micromanaging and enforces bad ideas about how their subordinates should do their jobs.
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 ~200 folks in a starting-to-get-there "Agile" model.
It is actually the worst for the managers - they spend a surprising amount of time noodling around in Jira to feed the workflows. For individual contributors, it works and isn't too much overhead.
From an administration standpoint, it is OK (we run the on-prem version). More stable than some enterprise monstrosities, but the with occasional problem. The plugin-store-thing is annoying - somehow it manages to entice nearly every new business-side user into asking for some random thing, they usually get what they want, and then they sit unused aside from occasionally breaking things.
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.
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 Confluence to begin with.
You'd think this would mean there was a healthy market for native client apps using the JIRA API with a more pleasant UI (as there certainly is for Git, e.g.), but strangely not.
Is there any other way?
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.
Not sure if that's better or worse, though.
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 that NEEDED to be included for some asinine reason.
Personal anecdote time: I had my interns start on Jira this summer. Three days in, I realized they weren't "getting" it because of how many damn buttons and knobs there are in the Jira UI. So, I switched all their issues to GitHub issues, and they went from having ~20 tickets in the project to over 100, and began adding, grooming, and closing their own without any input or direction from me. Sure, it's lackluster from an automation perspective, but they developed their own tagging system in the span of a few days and maintained their own board all summer.
I loved Atlassian for BitBucket in college, but when I entered the workforce and was forced to use Jira and Hipchat, I lost all love for them.
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!
"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.
https://github.com/tj/git-extras/blob/master/bin/git-undo
It won't help you if you don't understand what the last command did or when it overwrote local files; it'll just make everything worse.
After trying to find something I liked, I ended up porting crecord extension for Mercurial to Git: https://github.com/andrewshadura/git-crecord
If you had a look you'd see git add -i is not even close to it ;)
There are a number of git shortcuts defined in my zsh aliases [0]. It goes like:
# Git aliases
alias g='git'
alias ga='git add'
alias ghb='git browse' # hub
alias ghpr='git pull-request' # hub
alias gp='git push'
alias gpoh='git push origin HEAD'
...
[0] - https://github.com/sungwoncho/dotfiles/blob/master/zsh/alias...
[alias]
amend = commit --amend --no-edit
ls = ls-tree --name-only --full-name HEAD
tree = log --graph --decorate --oneline --all
commit-date = "!gitcommitdate() { (export GIT_COMMITTER_DATE=\"$1\" && git commit --date=\"${GIT_COMMITTER_DATE}\" \"${@:2}\"); } && gitcommitdate"
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
[1]: https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases [2]: https://github.com/nickbarnwell/dotfiles/blob/master/home/.e...
Whenever I have to touch git and `git co` doesn't work, I think, okay, fine, we'll go through the full dress rehearsal; `git checkout` it is.
Another tip, I only occasionally need git autocompletion withh aliases, but in zsh you can do something like this:
# Enable zsh git completion for our aliases.
# See https://github.com/mislav/dotfiles/blob/d82e79b8a500891a02ab28171974d68be7a35e12/shrc/git.sh
if [ -n "$ZSH_VERSION" ]; then
compdef _git g=git
compdef _git gc=git-commit
compdef _git gco=git-checkout
compdef _git gd=git-diff
compdef _git gb=git-branch
compdef _git gst=git-status
compdef _git gp=git-push
compdef _git gd=git-diff
fi
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.
Actually magit is quite fine for small personal projects. It's just that it absolutely chokes on a large monorepo I'm working on.
Just a few moments ago I had to kill Emacs because magit was executing this command:
git branch --remote --contains 10a1663bf96fI've been moving more and more to terminal for all of my development. My dev. stack is now: vim; tmux; lynx; ddgr; zsh; and docker. It is game changing for distraction-free programming, consistency between languages, and the ability to use the exact same setup everywhere -- even on remote machines.
Sharex is the other thing I mentioned, its screenshots/screenrecords on steroids, check it out.
This looks like it could be close, and I’ll definitely give it a try. If I could decouple myself a bit more from Sublime that would be great. The plugin community just isn’t the same as VS Code.
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.
I am a long time git tower user, and i have given GitKraken more than a few shots. I always go back to a hybrid command line and git tower workflow
go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH
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 obfuscate panic traces.
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?
https://golang.org/doc/go1.10#build
You can resolve this by using "all" as the pattern (-gcflags=all=-trimpath=$GOPATH)
I commit like, once a day. What am I doing wrong?
Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.
There are so many ways to approach a problem in any given codebase, and I rarely know which will be the best without experimenting. Having tools that reduce the burden of experimentation and branching is incredibly powerful.
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.
then got commit -v to verify the hunks
if people know an equivalent outside go, please comment
This tool looks like it does that a bit better with interactivity maintained, and for some reason i'm more comfortable accepting a CLI git UI into my workflow than a GUI.
Not a UI but helps with some commands you run in a row quite often
git_show_blame () {
if [ -z "$3" ]
then
printf "USAGE: git_show_blame filepath start_line_num end_line_num" && return 1
else
[ ! -z "$4" ] && printf "\\n${LPURP}[git_show_blame]${NC} Warning: extra arguments provided. Ignoring everything after the first 3\\n\\n"
git show $(git blame "$1" -L "$2","$3" | awk '{print $1}')
return $?
fi
}
* I acknowledge that some really great skiers are geeked on their equipment and use a variety of skis. Point still stands.
GitX (Mac only sadly) is the best of the free ones, and Tower is then best of the commercial ones. Try those.
This is the most ridiculous ad ever.