5 ms·

Play Git Like A Violin

135 points by mmphosis 16y ago

sjs 16y ago
Most git commands I use on a daily basis have 1-3 letter shell aliases: https://github.com/samsonjs/config/blob/master/zsh/zshrc#L238-291 https://github.com/samsonjs/config/blob/master/zsh/zshrc#L23... Previously on reddit: http://www.reddit.com/r/programming/comments/b0o6z/short_but_sweet_shell_aliases_and_global_aliases/ http://www.reddit.com/r/programming/comments/b0o6z/short_but...
sumeetjain 16y ago
Love the first one. Have you considered putting your dotfiles on GitHub? That way other people can fork them for their own use, and you can also browse your Fork Queue to see if others have made interesting additions/changes. Here's mine (mostly forked from a friend's): https://github.com/sumeetjain/dotfiles https://github.com/sumeetjain/dotfiles As an example, I have one git function (called 'gpa') that shoves everything in the staging area into a single commit and immediately pushes it. `gpa "the commit message"`
dustingetz 16y ago
the point aliases is to make executing the command fast enough that you aren't conscious of actually typing the command, which is one less thing to distract you. if you go to a computer without the alias, you'll probably interrupt your thought flow with every command. so in many work/team situations, the (larger) cost of changing terminals outweighs the (smaller) benefit of aliases.
jarin 16y ago
I do the same thing, and then I look like a dummy when I go to someone else's computer and keep typing "git st", "git co", "gphm" (git push heroku master), etc.
- deleted 16y ago
  [deleted]
- zoul 16y ago
  It's a pity that git doesn't also accept unique prefixes for each command like Subversion does. Is that by design?
  - JonnieCache 16y ago
    The help.autocorrect git-config variable allows it: Automatically correct and execute mistyped commands after waiting for the given number of deciseconds (0.1 sec). If more than one command can be deduced from the entered text, nothing will be executed. If the value of this option is negative, the corrected command will be executed immediately. If the value is 0 - the command will be just shown but not executed. This is the default. I think the alias system is better though.
  - deleted 16y ago
    [deleted]
mcobrien 16y ago
I use bash aliases for the same thing: alias gs='git status' alias gc='git commit -m' alias gca='git commit -a -m' alias gd='git diff' I spend most of my time with gs and gd, then usually gca my changes all at once, or add those I want and use gc.
- falcolas 16y ago
  I do the same. alias co='git checkout' alias gb='git branch' alias gd='git diff' alias gr='git reset --hard' alias gs='git status' alias gc='git commit' alias ga='git add' But I'm moving away from using git status as much, since adding the following to my $PS1: get_branch () { GS=$(git status 2>&1) if [ $? -eq 0 ] then STAR='*' echo $GS | grep 'nothing to commit' > /dev/null 2>&1 && STAR='' echo -ne "$(echo $GS | grep 'On branch' | cut -d' ' -f4)${STAR}" else echo -ne '_' fi } It's a bit slow some days (up to a second to pop up a prompt when the box is busy), but the constant visual reference to my branch name & uncommitted changes is nice.
  - mattyb 16y ago
    You may find this useful: http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/completion/git-completion.bash;hb=HEAD http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/... It can tell you if your working directory is dirty, if you've got staged changes, what branch/tag you're on, and of course does completion also.
- Peaker 16y ago
  Instead of "git diff" followed by "git commit -a -m", I like to do: "git add -p" followed by commit. You get to see the diff, piece by piece, and separate the independent fixes.
- deleted 16y ago
  [deleted]
patio11 16y ago
Swiping that first one - I have hundreds of commits which were just one or two character tweaks after I had hit the commit button. Often, they squash bugs. (Hah, test run completed and now I realize the error of my ways...) More articles like this, please?
- deleted 16y ago
  [deleted]
- hayeah 16y ago
  Glad you like it. Another weird thing I do is that "g" is not just an alias, it's a function in my ~/.bashrc So "g" (without any argument) is "g status", with arguments, g is effectively an alias for git. A micro-optimization, true. Another git feature I use quite a bit is the history rewrite. "git fuss 5" allows me to fiddle with the last 5 commits. I should write another article to explain git fuss. History rewrite sounds like a dirty thing. But my git workflow involves doing a whole bunch of temporary commits, so I can track small incremental steps with git. History rewrite is pretty legit for this usage pattern. g() { if [[ $# == '0' ]]; then git status else case $1 in fuss) shift git rebase -i HEAD~"$1";; *) git "$@";; esac fi }
  - dustingetz 16y ago
    > History rewrite sounds like a dirty thing well you're only rewriting local history, so you're a-ok. history re-writing becomes a dirty word when you re-write history that someone else may have already seen. i know you already know this.
    - cpeterso 16y ago
      > history re-writing becomes a dirty word when you re-write history that someone else may have already seen. It seems like git (or some friendlier wrapper) could track this for you. For example, if you've pushed changes to a remote repo, then git could mark those changes as "published" in your local repo and warn you when you later try to rewrite that branch's history.
gtani 16y ago
http://www.opsb.co.uk/?p=56 http://www.opsb.co.uk/?p=56 http://paulbarry.com/articles/2009/01/20/my-git-workflow http://paulbarry.com/articles/2009/01/20/my-git-workflow http://www.viget.com/inspire/terminal-aliases-for-git/ http://www.viget.com/inspire/terminal-aliases-for-git/ http://git.or.cz/gitwiki/Aliases http://git.or.cz/gitwiki/Aliases
ch0wn 16y ago
This one is pretty neat: "git commit -a --amend -C HEAD" Happens to me all the time I forgot to stage a certain file or made a small typo.
- Peaker 16y ago
  git commit --amend -aCHEAD
- adimitrov 16y ago
  You don't really need '-C HEAD' at all. The default behavior is to just reuse the last commit message, which is, implicitly, HEAD.
  - cmurphycode 16y ago
    That doesn't work for me. git commit -a --amend prompts for commit message in $editor git commit -a --amend -C complains about lack of input Maybe this is a git version specific thing.
- Estragon 16y ago
  Is there a way to do that in hg?
silentbicycle 16y ago
I'm surprised more people don't do this stuff. AFAIK, the only single-letter Unix command or widely installed program is 'w', the rest are up for grabs.
sfvisser 16y ago
These aliases are truly useful, but watch out for mistakes. I can still vividly remember the moment I mistakenly typed in "g co src/" instead of "g ci src/". I immediately changed my checkout alias to "cho".
- Peaker 16y ago
  That's one of the things I hate about git (I like git a lot, in general). It makes it too easy to make irreversible damage. "git clean", "git reset --hard", "git checkout" all provide ways to irreversibly trash the working tree. "git clean" has no other function except doing irreversible deletions, so that's OK, IMO. "git reset --hard" is a pretty useful way to make a branch jump around between places, so having a secondary feature of trashing the working tree is unacceptable, IMO. "git checkout" is a useful way to take a file from a specific commit. The fact it may also trash uncommitted changes is also a secondary feature. I think without "--force", "checkout" should refuse to irreversibly lose content.
  - 198d 16y ago
    If you take a look at the man pages for all of those commands you'll see they explicitly mention that your working tree will be affected. They are written explicitly to do that. 'git reset' can be called with '--mixed' or '--keep' which might be more along the lines of what you're looking for. If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do.
    - Peaker 16y ago
      > If you take a look at the man pages for all of those commands you'll see they explicitly mention that your working tree will be affected. I'm not complaining that these commands mismatch the spec. I'm complaining that the spec for these commands is badly designed. > They are written explicitly to do that I agree about git clean, but git reset --hard and git checkout do more than just changing the working tree. > If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do. You misunderstood my problem. I know exactly what these commands do. I consider "reverting my changes in the working tree" to be a separate and irreversible thing of whatever "git reset" and "git checkout" do, and want git to ask for approval before accidentally doing irreversible damage. The main thing protecting me from accidental errors/deletions/etc is my revision control system. But in this case, the irreversible damage is done BY the revision control system. Here are a few examples of what I mean: * I jump to the wrong shell. In it, I have an old "git status" that says my working tree is clean, but at the wrong location. I forget that I already moved it, and started working on a feature. I use "git reset --hard <correct-place>" and without warning, I also get my working tree changes irreversibly lost without any question. * I press <up> a few times in my shell, to reach a previous command, hit <return>. OOPS, that command was not the one I intended. Instead it was a "git reset --hard <someplace>" or perhaps a "git checkout"! * I may execute a command like "git checkout <refspec> <some_path>" during a merge in order to pick some version of that file. If I accidentally press <return> too early, I may lose all of my working tree changes in the directory. I don't actually lose my working tree changes with git, because I'm aware of these issues, so I am very careful about which commands I replay. But it would be nice to know that since I have a revision control backup of my files, I don't need to be as careful, as long as I don't use "clean", "rm" and other commands meant to lose information. P.S: It would be nice if "checkout" stored a stash or such of any overwritten content so it isn't irreversible unless given a flag not to. tl;dr: Good UI design dictates that user operations should be reversible whenever possible. Irreversible operations should require explicit confirmation (or at least "--force") and ideally should have no other effect except the specific irreversibility.
yogsototh 16y ago
I trully believe that no one should use "git reset --hard" unless really know what he is doing (understand for beginer). This is why, I aliased an "uncommit". You can see the details in this article[1] I had written for my friend who were learning git. usage: git uncommit 3 effect: add another point in the history where it is said you get back 3 commit in time. Which is better in most case than modifying the history when you want to push it. [1]: http://yannesposito.com/Scratch/en/blog/2009-11-12-Git-for-n00b/conf-et-install/ http://yannesposito.com/Scratch/en/blog/2009-11-12-Git-for-n...
kirubakaran 16y ago
If you are an Emacs user, use magit. Changed my life.
cpeterso 16y ago
I like easygit (eg). It's training wheels wrapper for git. You use "real" git commands, but easygit has safer defaults and extra sanity checks (like forgetting to stage modified files). The help messages are more verbose and use more consistent terminology than git's man pages. For example, easygit always uses the term "staged" instead of "index/staged/add/hard/soft/mixed/cached/HEAD/etc." http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/

135 points by mmphosis 16y ago

sjs 16y ago

Most git commands I use on a daily basis have 1-3 letter shell aliases: https://github.com/samsonjs/config/blob/master/zsh/zshrc#L238-291 https://github.com/samsonjs/config/blob/master/zsh/zshrc#L23... Previously on reddit: http://www.reddit.com/r/programming/comments/b0o6z/short_but_sweet_shell_aliases_and_global_aliases/ http://www.reddit.com/r/programming/comments/b0o6z/short_but...

sumeetjain 16y ago

Love the first one. Have you considered putting your dotfiles on GitHub? That way other people can fork them for their own use, and you can also browse your Fork Queue to see if others have made interesting additions/changes. Here's mine (mostly forked from a friend's): https://github.com/sumeetjain/dotfiles https://github.com/sumeetjain/dotfiles As an example, I have one git function (called 'gpa') that shoves everything in the staging area into a single commit and immediately pushes it. `gpa "the commit message"`

dustingetz 16y ago

the point aliases is to make executing the command fast enough that you aren't conscious of actually typing the command, which is one less thing to distract you. if you go to a computer without the alias, you'll probably interrupt your thought flow with every command. so in many work/team situations, the (larger) cost of changing terminals outweighs the (smaller) benefit of aliases.

jarin 16y ago

I do the same thing, and then I look like a dummy when I go to someone else's computer and keep typing "git st", "git co", "gphm" (git push heroku master), etc.

deleted 16y ago
[deleted]
zoul 16y ago
It's a pity that git doesn't also accept unique prefixes for each command like Subversion does. Is that by design?
- JonnieCache 16y ago
  The help.autocorrect git-config variable allows it: Automatically correct and execute mistyped commands after waiting for the given number of deciseconds (0.1 sec). If more than one command can be deduced from the entered text, nothing will be executed. If the value of this option is negative, the corrected command will be executed immediately. If the value is 0 - the command will be just shown but not executed. This is the default. I think the alias system is better though.
- deleted 16y ago
  [deleted]

mcobrien 16y ago

I use bash aliases for the same thing: alias gs='git status' alias gc='git commit -m' alias gca='git commit -a -m' alias gd='git diff' I spend most of my time with gs and gd, then usually gca my changes all at once, or add those I want and use gc.

falcolas 16y ago
I do the same. alias co='git checkout' alias gb='git branch' alias gd='git diff' alias gr='git reset --hard' alias gs='git status' alias gc='git commit' alias ga='git add' But I'm moving away from using git status as much, since adding the following to my $PS1: get_branch () { GS=$(git status 2>&1) if [ $? -eq 0 ] then STAR='*' echo $GS | grep 'nothing to commit' > /dev/null 2>&1 && STAR='' echo -ne "$(echo $GS | grep 'On branch' | cut -d' ' -f4)${STAR}" else echo -ne '_' fi } It's a bit slow some days (up to a second to pop up a prompt when the box is busy), but the constant visual reference to my branch name & uncommitted changes is nice.
- mattyb 16y ago
  You may find this useful: http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/completion/git-completion.bash;hb=HEAD http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/... It can tell you if your working directory is dirty, if you've got staged changes, what branch/tag you're on, and of course does completion also.
Peaker 16y ago
Instead of "git diff" followed by "git commit -a -m", I like to do: "git add -p" followed by commit. You get to see the diff, piece by piece, and separate the independent fixes.
deleted 16y ago
[deleted]

patio11 16y ago

Swiping that first one - I have hundreds of commits which were just one or two character tweaks after I had hit the commit button. Often, they squash bugs. (Hah, test run completed and now I realize the error of my ways...) More articles like this, please?

deleted 16y ago
[deleted]
hayeah 16y ago
Glad you like it. Another weird thing I do is that "g" is not just an alias, it's a function in my ~/.bashrc So "g" (without any argument) is "g status", with arguments, g is effectively an alias for git. A micro-optimization, true. Another git feature I use quite a bit is the history rewrite. "git fuss 5" allows me to fiddle with the last 5 commits. I should write another article to explain git fuss. History rewrite sounds like a dirty thing. But my git workflow involves doing a whole bunch of temporary commits, so I can track small incremental steps with git. History rewrite is pretty legit for this usage pattern. g() { if [[ $# == '0' ]]; then git status else case $1 in fuss) shift git rebase -i HEAD~"$1";; *) git "$@";; esac fi }
- dustingetz 16y ago
  > History rewrite sounds like a dirty thing well you're only rewriting local history, so you're a-ok. history re-writing becomes a dirty word when you re-write history that someone else may have already seen. i know you already know this.
  - cpeterso 16y ago
    > history re-writing becomes a dirty word when you re-write history that someone else may have already seen. It seems like git (or some friendlier wrapper) could track this for you. For example, if you've pushed changes to a remote repo, then git could mark those changes as "published" in your local repo and warn you when you later try to rewrite that branch's history.

gtani 16y ago

http://www.opsb.co.uk/?p=56 http://www.opsb.co.uk/?p=56 http://paulbarry.com/articles/2009/01/20/my-git-workflow http://paulbarry.com/articles/2009/01/20/my-git-workflow http://www.viget.com/inspire/terminal-aliases-for-git/ http://www.viget.com/inspire/terminal-aliases-for-git/ http://git.or.cz/gitwiki/Aliases http://git.or.cz/gitwiki/Aliases

ch0wn 16y ago

This one is pretty neat: "git commit -a --amend -C HEAD" Happens to me all the time I forgot to stage a certain file or made a small typo.

Peaker 16y ago
git commit --amend -aCHEAD
adimitrov 16y ago
You don't really need '-C HEAD' at all. The default behavior is to just reuse the last commit message, which is, implicitly, HEAD.
- cmurphycode 16y ago
  That doesn't work for me. git commit -a --amend prompts for commit message in $editor git commit -a --amend -C complains about lack of input Maybe this is a git version specific thing.
Estragon 16y ago
Is there a way to do that in hg?

silentbicycle 16y ago

I'm surprised more people don't do this stuff. AFAIK, the only single-letter Unix command or widely installed program is 'w', the rest are up for grabs.

sfvisser 16y ago

These aliases are truly useful, but watch out for mistakes. I can still vividly remember the moment I mistakenly typed in "g co src/" instead of "g ci src/". I immediately changed my checkout alias to "cho".

Peaker 16y ago
That's one of the things I hate about git (I like git a lot, in general). It makes it too easy to make irreversible damage. "git clean", "git reset --hard", "git checkout" all provide ways to irreversibly trash the working tree. "git clean" has no other function except doing irreversible deletions, so that's OK, IMO. "git reset --hard" is a pretty useful way to make a branch jump around between places, so having a secondary feature of trashing the working tree is unacceptable, IMO. "git checkout" is a useful way to take a file from a specific commit. The fact it may also trash uncommitted changes is also a secondary feature. I think without "--force", "checkout" should refuse to irreversibly lose content.
- 198d 16y ago
  If you take a look at the man pages for all of those commands you'll see they explicitly mention that your working tree will be affected. They are written explicitly to do that. 'git reset' can be called with '--mixed' or '--keep' which might be more along the lines of what you're looking for. If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do.
  - Peaker 16y ago
    > If you take a look at the man pages for all of those commands you'll see they explicitly mention that your working tree will be affected. I'm not complaining that these commands mismatch the spec. I'm complaining that the spec for these commands is badly designed. > They are written explicitly to do that I agree about git clean, but git reset --hard and git checkout do more than just changing the working tree. > If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do. You misunderstood my problem. I know exactly what these commands do. I consider "reverting my changes in the working tree" to be a separate and irreversible thing of whatever "git reset" and "git checkout" do, and want git to ask for approval before accidentally doing irreversible damage. The main thing protecting me from accidental errors/deletions/etc is my revision control system. But in this case, the irreversible damage is done BY the revision control system. Here are a few examples of what I mean: * I jump to the wrong shell. In it, I have an old "git status" that says my working tree is clean, but at the wrong location. I forget that I already moved it, and started working on a feature. I use "git reset --hard <correct-place>" and without warning, I also get my working tree changes irreversibly lost without any question. * I press <up> a few times in my shell, to reach a previous command, hit <return>. OOPS, that command was not the one I intended. Instead it was a "git reset --hard <someplace>" or perhaps a "git checkout"! * I may execute a command like "git checkout <refspec> <some_path>" during a merge in order to pick some version of that file. If I accidentally press <return> too early, I may lose all of my working tree changes in the directory. I don't actually lose my working tree changes with git, because I'm aware of these issues, so I am very careful about which commands I replay. But it would be nice to know that since I have a revision control backup of my files, I don't need to be as careful, as long as I don't use "clean", "rm" and other commands meant to lose information. P.S: It would be nice if "checkout" stored a stash or such of any overwritten content so it isn't irreversible unless given a flag not to. tl;dr: Good UI design dictates that user operations should be reversible whenever possible. Irreversible operations should require explicit confirmation (or at least "--force") and ideally should have no other effect except the specific irreversibility.

yogsototh 16y ago

I trully believe that no one should use "git reset --hard" unless really know what he is doing (understand for beginer). This is why, I aliased an "uncommit". You can see the details in this article[1] I had written for my friend who were learning git. usage: git uncommit 3 effect: add another point in the history where it is said you get back 3 commit in time. Which is better in most case than modifying the history when you want to push it. [1]: http://yannesposito.com/Scratch/en/blog/2009-11-12-Git-for-n00b/conf-et-install/ http://yannesposito.com/Scratch/en/blog/2009-11-12-Git-for-n...

kirubakaran 16y ago

If you are an Emacs user, use magit. Changed my life.

cpeterso 16y ago

I like easygit (eg). It's training wheels wrapper for git. You use "real" git commands, but easygit has safer defaults and extra sanity checks (like forgetting to stage modified files). The help messages are more verbose and use more consistent terminology than git's man pages. For example, easygit always uses the term "staged" instead of "index/staged/add/hard/soft/mixed/cached/HEAD/etc." http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/