All valid points. The main reason why people resort to aliases is how unintuitive git command line interface is. For example I have an alias called git unstage because git reset HEAD -- doesn't actually explain anything at all to me, no matter how many times I look at it. I did always end up googling "how to unstage files" or "how to undo last commit" in the past.
Same goes for "git cherry", the documentation for cherry is Find commits yet to be applied to upstream. They could have called it "git whatever", it speaks to me as little as the word cherry does.
Some aliases are also to shortcut long commands, like git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short.
I agree that you can go overboard with aliases, but I still think there's value in having them
That's a reasonable argument, and used like that it's definitely a beneficial approach. The aliases that most people mention, however, seem to be minimalistic acronyms, which suggests character reduction as the primary goal.
I am so-so on aliases; I think they make a lot of sense for stuff like git unstage -- ie, taking something and adding a name and meaning that is clearer. Sort of like how if there is a function from an API I am using all the time whose name I find confusing/unclear, I will just make a tiny wrapper function with a name that makes sense, etc. Stuff like gcma to me is sort of like taking document.getElementById and shadowing it to document.gebi
It's worth noting, also, that git aliases are (or should be) aliased within git, as it adds a lot of nice features:
$git aliasunstage = reset HEAD --
$git unstage --help# or$git help unstage
'unstage' is aliased to 'reset HEAD --'
$git unstag
git: 'unstag' is not a git command. See 'git --help'.
The most similar command is
unstage
That's a lot less terribad than wrapping the same thing in a shell alias or function. Shell aliases for git commands are especially dumb because you're both circumventing many of git's better features, and creating something that's susceptible to all of the issues raised here.
(It's almost as if, knowing their command structure might be... let's say "less than intuitive", the git developers at least decided to include good tools for mitigating that problem.)
I have also seen some really long/complex-looking git aliases that are really hard to follow, like:
[alias]
foo = !"f() { some; really && long | function onliner || with lots of $(sed) && awk '{print $1}' && then call --it at 'the' end ; } ; f"
For these cases, I would recommend creating an executable script placed somewhere in your $PATH named git-foo and git will expose this as a subcommand, like $ git foo. Just like git-extras.
All valid points. The main reason why people resort to aliases is how unintuitive git command line interface is. For example I have an alias called
git unstagebecausegit reset HEAD --doesn't actually explain anything at all to me, no matter how many times I look at it. I did always end up googling "how to unstage files" or "how to undo last commit" in the past.Same goes for "git cherry", the documentation for cherry is
Find commits yet to be applied to upstream. They could have called it "git whatever", it speaks to me as little as the word cherry does.Some aliases are also to shortcut long commands, like
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short.I agree that you can go overboard with aliases, but I still think there's value in having them
That's a reasonable argument, and used like that it's definitely a beneficial approach. The aliases that most people mention, however, seem to be minimalistic acronyms, which suggests character reduction as the primary goal.
I am so-so on aliases; I think they make a lot of sense for stuff like
git unstage-- ie, taking something and adding a name and meaning that is clearer. Sort of like how if there is a function from an API I am using all the time whose name I find confusing/unclear, I will just make a tiny wrapper function with a name that makes sense, etc. Stuff likegcmato me is sort of like takingdocument.getElementByIdand shadowing it todocument.gebiYeah, I try not to alias git commands to acronyms, it makes my life harder.
It's worth noting, also, that
gitaliases are (or should be) aliased withingit, as it adds a lot of nice features:That's a lot less terribad than wrapping the same thing in a shell alias or function. Shell aliases for git commands are especially dumb because you're both circumventing many of git's better features, and creating something that's susceptible to all of the issues raised here.
(It's almost as if, knowing their command structure might be... let's say "less than intuitive", the git developers at least decided to include good tools for mitigating that problem.)
I have also seen some really long/complex-looking git aliases that are really hard to follow, like:
For these cases, I would recommend creating an executable script placed somewhere in your
$PATHnamedgit-fooand git will expose this as a subcommand, like$ git foo. Just like git-extras.Agreed, as an alias abuse that's just obnoxious.
Actually I guess
git aliasis part of git-extras, not core git. I guess I never noticed before, since it's just sort of always been there.