Hacker News Reader

Comment by jolmg | Hacker News Reader

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

View on HN

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 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/

In my experience of using git integration features in IntelliJ, they are nice for simple tasks like quickly checking the status of a file or committing all the changes, but as soon as I need to do more complex tasks in git, I find the UIs either get in the way and slow me down or just aren’t fully featured enough to do what I need to do and I end up back on the command line. Hence why I always encourage newcomers to git to learn both if possible.

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.

Git integration in IntelliJ is terrible IMO. It conflates staging and committing, and unstaging with reverting. I don't use it because it is a PITA, but what is even more annoying are the PR's from team members who do use it, which I have to send immediately back due to random files.

The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history.

I've never used it for anything else git related because the ui is strange.

True, but frankly it is Git’s model that is broken, or at the very least overcomplicated.

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.

> 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 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 prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?

I agree with this. Strongly.

> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?

Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs should support Git.

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

I do a git diff after every git status before adding/committing. Do IDEs show diff before committing? Jetbrains IDEs do show diff between subsequent commits. Although they do highlight which files have been modified.

> Do IDEs show diff before committing?

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).

My IDE is bash. I use almost always use emacs -nw for editing text. While there are git front ends for emacs, I almost never bother with them. I can't remember what I've memorised about the git CLI, but usually I don't find the CLI troublesome. YMMV.

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

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.

I only expect my editor to read some information from my git repository. Gutters displaying new/modified hunks and shortcuts to jump to them are pretty much the only things I find useful (for my use; I understand some will find other features helpful).

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.

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

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.

I turned off everything, autocomplete (the auto drop down menu style), the status bar, line numbers, git gutter, color changes from git in the tree view, live linting. Main thing enabled is auto format on save, and a bunch of 1-2 letter aliases for common commands. My editor is a sea of calm tranquility now.

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.

Unless you're on someone else's machine. Then you'll still need the cli.

In that case one should stick to using vanilla git with no aliases, shortcuts, etc.

> intellij idea have excellent git integration.

I find all the colors and ques distracting while I am coding.

I used the ide interaction then moved to the terminal once I realized there are really only a subset of commands you need to know. There are visual things that are still handy that the ide does, but to perform commands, I feel like the terminal is more explicit and you know what subsequent steps you’re taking (relatively, of course).

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'm also not tired of typing git commands. It seems almost natural now. With that said, this individual spent their free time to create something using their skills which they perceived to be an improvement/optimization upon their skill-set and shared it with the world.

IMHO, that's commendable.

It definitely is. I didn't mean to sound dismissive of his work, but I can see how it does. My intent was rather to inform those who haven't realized, OP seemingly included, that the shell can be very efficient to work with. I can't see myself using this tool and being more productive than I already am with the shell, but I can still appreciate the effort and generosity in making it available to the world.

I mean, to be fair, you are essentially saying you are not tired of typing git commands only because you type shorthands you've created. It feels like you're raining on his parade a bit because he didn't do the same thing you did.

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.

> I mean, to be fair, you are essentially saying you are not tired of typing git commands only because you type shorthands you've created. It feels like you're raining on his parade a bit because he didn't do the same thing you did.

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.

I'm not. I use GitHub Desktop for commits (with a subset of changed lines sometimes), pushing, pulling, merging, creating and deleting branches, looking at changes I did since the latest commit. I've used command line for changing executable bit in index once.

If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run.

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.

Seconding the in-editor approach. Magit is wonderful (though I often do end up heading to the command-line for certain things out of habit).

I think it's good to keep doing some things via command line, so as not to forget how Git works "under the hood". I also keep my Git alias commands to a minimum for a similar reason.

For me flow is important, so that I don't get distracted when working. The best way to achieve this is having single key shortcuts.

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.

> If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run.

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.

> That sounds like limiting the functionality of the whole computer to what the text editor can do.

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>`

> Next, you'll want to browse the web from the editor

Well, you're clearly replying to an emacs user. He/she will not find that statement the least hyperbolic.

I do. I use a separate browser. There are people who want to do everything from their editors. There are people who want to do only editing in the editor.

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.

That's a terrible analogy. I only use git with my IDEs and only use my IDEs with git (except one weird outside project at work where I have to use a partner company's TFS). So integration makes complete sense. Hell, that's true whether you use CLI or GUI. I use my browser for an infinite variety of different activities, only a tiny subset of which relate to my IDE.

Phil Haack has a nice set of aliases that I've grown reliant on: https://haacked.com/archive/2014/07/28/github-flow-aliases/

Learning git by heart has immense value if you've got a team that doesn't grok rebasing and merging or just a cross-functional team with QA's commiting to a monorepo.

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.

Since `git status` is my most common command I've got it aliased to just `s`. Every time I use another machine it throws me off when the command doesn't work :)

I use `s` to launch a new terminal window in the same directory as the shell that called it. This way, I launch a terminal, go to a project directory, and then type s<enter> a few times to get sufficient terminals in that context.

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.

You might want to check out tmux. I've changed my terminal to "st -c tmux" and every time I open a terminal window I get access to multiple frames, (nearly) infinite scrolling, window management and more.

I use tmux when I'm connected on a remote computer and want to do a command that takes a long time and that I don't want to kill if I happen to cut the connection for any reason (e.g. I leave the wifi range).

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.

I have similar ones set up. 'Pull' and 'push'. Though some days I'm tempted to map all the old SCUMM keyboard shortcuts here.

'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

This is why I advocate against aliases. History is universal, more powerful and needs zero configuration. ^r and few keys takes me to any command part of my daily repertoire. It really shines as the commands get more and more verbose.

^rstat -> git status

^rcomm -> git commit

^rkout -> git checkout -d foo

^redit -> git commit --amend --no-edit

^rdeco -> git commit --oneline --decorate

I also aliased git to g, so I can type "g l" for git log.

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 bound hstr to CTRL-R (https://github.com/dvorka/hstr) and then just search the history for the keywords I need. Only rarely is a command not already stored in the history.

I use zsh + antigen + oh-my-zsh's git plugin which comes with a lot of aliases. For example, `git status` is `gst`: https://github.com/robbyrussell/oh-my-zsh/blob/b6ca933a02ed7...

What is `<esc>kF-aa<enter>`?

He's referring to the vi command sequence he would type to amend his command, i.e. OP has 'set -o vi' in his shellrc or 'set editing-mode vi' in his inputrc

    # 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
    $ |

I use TextExpander (I wish there was something comparable on Linux!) and I have aliases defined:

,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.

Reply on news.ycombinator.com