5 ms·

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

by jolmg 8y ago

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

frenchie14 8y ago
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 :)
- jolmg 8y ago
  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.
  - terminalcommand 8y ago
    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.
    - jolmg 8y ago
      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.
- roryisok 8y ago
  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
- akula1001 8y ago
  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
eljimmy 8y ago
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.
- jolmg 8y ago
  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.
  - sushid 8y ago
    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.
    - jolmg 8y ago
      > 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.
red75prime 8y ago
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.
sv123 8y ago
Phil Haack has a nice set of aliases that I've grown reliant on: https://haacked.com/archive/2014/07/28/github-flow-aliases/ https://haacked.com/archive/2014/07/28/github-flow-aliases/
dmortin 8y ago
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.
- yellowapple 8y ago
  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).
  - john2x 8y ago
    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.
    - dmortin 8y ago
      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.
- jolmg 8y ago
  > 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.
hyperpallium 8y ago
What is `<esc>kF-aa<enter>`?
- remar 8y ago
  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 $ |
hv42 8y ago
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/ http://stevelosh.com/blog/2013/04/git-koans/
- kelnage 8y ago
  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.
  - Normal_gaussian 8y ago
    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.
    - korm 8y ago
      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.
qznc 8y ago
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.
smnscu 8y ago
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/b6ca933a02ed780c8ed776e74b141e45a5389f98/plugins/git/git.plugin.zsh#L231 https://github.com/robbyrussell/oh-my-zsh/blob/b6ca933a02ed7...
jwr 8y ago
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.
zamber 8y ago
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.
jmiserez 8y ago
I bound hstr to CTRL-R (https://github.com/dvorka/hstr 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.

by jolmg 8y ago

frenchie14 8y ago

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

jolmg 8y ago
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.
- terminalcommand 8y ago
  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.
  - jolmg 8y ago
    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.
roryisok 8y ago
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
akula1001 8y ago
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

eljimmy 8y ago

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.

jolmg 8y ago
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.
- sushid 8y ago
  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.
  - jolmg 8y ago
    > 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.

red75prime 8y ago

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.

sv123 8y ago

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

dmortin 8y ago

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.

yellowapple 8y ago
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).
- john2x 8y ago
  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.
  - dmortin 8y ago
    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.
jolmg 8y ago
> 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.

hyperpallium 8y ago

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

remar 8y ago
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 $ |

hv42 8y ago

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/ http://stevelosh.com/blog/2013/04/git-koans/

kelnage 8y ago
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.
- Normal_gaussian 8y ago
  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.
  - korm 8y ago
    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.

qznc 8y ago

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.

smnscu 8y ago

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/b6ca933a02ed780c8ed776e74b141e45a5389f98/plugins/git/git.plugin.zsh#L231 https://github.com/robbyrussell/oh-my-zsh/blob/b6ca933a02ed7...

jwr 8y ago

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.

zamber 8y ago

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.

jmiserez 8y ago

I bound hstr to CTRL-R (https://github.com/dvorka/hstr 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.