From: Ondrej Certik <hidden> Date: 2016-06-15 22:47:02
Hi,
coming to git from mercurial and svn, here is the alias part of my .gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
What is the view on this in the git community? Do most of you write
git checkout -b branch ...
(possibly with TAB completion) or do most of you write
git co -b branch ...
(like I do all the time, except when sharing my commands with other people)?
Could in principle those aliases be even made default by git? Or is
this not a good idea.
Ondrej
From: Jakub Narebski <hidden> Date: 2016-06-15 22:47:02
Ondrej Certik [off-list ref] writes:
coming to git from mercurial and svn, here is the alias part of my
.gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
If you have admin rights on the machine, you can do that either using
system git config file (git config --system) i.e. $(prefix)/etc/gitconfig
or rather $(sysconfdir)/gitconfig, or by providing 'config' template
(copied as default repository config on init) in some place like
/usr/share/git-core/templates/config .
What is the view on this in the git community? Do most of you write
git checkout -b branch ...
(possibly with TAB completion) or do most of you write
git co -b branch ...
(like I do all the time, except when sharing my commands with other
people)?
I use tab completion for commands like "git commit", "git show", "git
checkout" etc. (most important part is branch completion, not command
completion IMVHO).
But I do have few aliases:
[alias]
cat = cat-file -p
less = -p cat-file -p
alias = config --get-regexp ^alias\\.
lg = log --pretty=oneline --abbrev-commit
one = show -s --pretty='format:%h (%s)'
llog = log --date=local
who = "!sh -c 'git log -1 --pretty=\"format:%an <%ae>\" --author=\"$1\"' -"
lb = for-each-ref --format='%(refname)' \
--sort=-authordate --count=8 refs/heads/
rllog = log -g --date=relative
rlg = reflog show @{now}
sed = !git ls-files --stage | grep ^100 | awk '{print $4}' | xargs sed
I use most often "git one" aliase (hmmm... I have just noticed that
"git lg" alias is now superfluous with new '--oneline' option).
Could in principle those aliases be even made default by git? Or is
this not a good idea.
The "default/built-in aliases" idea was discussed on git mailing list
a few times in the past...
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:47:02
Ondrej Certik wrote:
Hi,
coming to git from mercurial and svn, here is the alias part of my .gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
What is the view on this in the git community?
Personally I think "plain" aliases like you use above are evil.
git is not svn or mercurial. If you use it like svn you'll be
surprised sooner or later and your workflow will feel awkward or
just plain wrong. hg and git are very similar, but the fact that
hg assumed the svn shorthands implies to me that they've tried
to retain a compatibility that does not, in fact, exist. DVCS
systems are enormously different from centralized ones. Borrowing
from centralized ones to a DVCS one feels utterly backwards.
Do most of you write
git checkout -b branch ...
(possibly with TAB completion) or do most of you write
git co -b branch ...
(like I do all the time, except when sharing my commands with other people)?
I have no simple aliases for any of the commands. There's just no reason
for them since tab completion works so well.
I do have one alias, which is "wsfix". It fixes whitespace fsckups I've
added to the index but not yet committed to the worktree. It's not a
particularly complex one, but not exactly simple either.
Could in principle those aliases be even made default by git? Or is
this not a good idea.
I see no reason to add default aliases. It will make a mess of things
when trying to explain workflows to people who have older versions of
git where those default aliases aren't available. It'll add complexity
to explanations, which is never a good thing.
If I have a vote, I vote no.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:47:02
Andreas Ericsson venit, vidit, dixit 09.07.2009 09:00:
Ondrej Certik wrote:
quoted
Hi,
coming to git from mercurial and svn, here is the alias part of my .gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
What is the view on this in the git community?
Personally I think "plain" aliases like you use above are evil.
git is not svn or mercurial. If you use it like svn you'll be
surprised sooner or later and your workflow will feel awkward or
just plain wrong. hg and git are very similar, but the fact that
hg assumed the svn shorthands implies to me that they've tried
to retain a compatibility that does not, in fact, exist. DVCS
systems are enormously different from centralized ones. Borrowing
from centralized ones to a DVCS one feels utterly backwards.
quoted
Do most of you write
git checkout -b branch ...
(possibly with TAB completion) or do most of you write
git co -b branch ...
(like I do all the time, except when sharing my commands with other people)?
I have no simple aliases for any of the commands. There's just no reason
for them since tab completion works so well.
I do have one alias, which is "wsfix". It fixes whitespace fsckups I've
added to the index but not yet committed to the worktree. It's not a
particularly complex one, but not exactly simple either.
quoted
Could in principle those aliases be even made default by git? Or is
this not a good idea.
I see no reason to add default aliases. It will make a mess of things
when trying to explain workflows to people who have older versions of
git where those default aliases aren't available. It'll add complexity
to explanations, which is never a good thing.
If I have a vote, I vote no.
Adding my no-vote to that, too.
Aliases are great, but default aliases are a problem. We saw this when
we introduced "git stage", and I don't think we're happy in retrorespect.
Having said that, collecting useful aliases (e.g. one, who, ...) in
contrib/ or in the wiki would be helpful.
Michael
From: Luciano Miguel Ferreira Rocha <hidden> Date: 2016-06-15 22:47:02
On Thu, Jul 09, 2009 at 09:00:30AM +0200, Andreas Ericsson wrote:
Ondrej Certik wrote:
quoted
Hi,
coming to git from mercurial and svn, here is the alias part of my
.gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
What is the view on this in the git community?
Personally I think "plain" aliases like you use above are evil.
git is not svn or mercurial. If you use it like svn you'll be
surprised sooner or later and your workflow will feel awkward or
just plain wrong. hg and git are very similar, but the fact that
hg assumed the svn shorthands implies to me that they've tried
to retain a compatibility that does not, in fact, exist.
No, it just means that shorting common commands is useful and common.
I have no simple aliases for any of the commands. There's just no reason
for them since tab completion works so well.
"Intelligent" bash completion always gets in my way, so I can't use it.
I vote yes.
--
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>
I like that one. It's going to be very handy for when I post commit
messages to my project newsgroup, as a subject title.
I use most often "git one" aliase (hmmm... I have just noticed that
"git lg" alias is now superfluous with new '--oneline' option).
:-) I only learned about --oneline yesterday myself and was going to
mention that to you. You beat me to it.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
I also gave from SVN and I must admit, I did create co, st, ci aliases,
but basically never used them, so removed them since. Git is not SVN, so
why treat it as such.
Alternatively, you can put your alias somewhere on a wiki or personal
web page and just refer user to look at your alias list, instead of
having to explain to them every time why your git commands are
non-standard. It might save you some time and effort - in the long run.
Or just learn the full git commands. ;-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
Having said that, collecting useful aliases (e.g. one, who, ...) in
contrib/ or in the wiki would be helpful.
+1 to that. I only spotted the 'one' alias now. So simple yet very
handy. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
From: Jakub Narebski <hidden> Date: 2016-06-15 22:47:02
On Thu, 9 July 2009, Michael J Gruber wrote:
[...]
Aliases are great, but default aliases are a problem. We saw this when
we introduced "git stage", and I don't think we're happy in
retrorespect.
Having said that, collecting useful aliases (e.g. one, who, ...) in
contrib/ or in the wiki would be helpful.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:47:02
Jakub Narebski venit, vidit, dixit 09.07.2009 11:40:
On Thu, 9 July 2009, Michael J Gruber wrote:
[...]
quoted
Aliases are great, but default aliases are a problem. We saw this when
we introduced "git stage", and I don't think we're happy in
retrorespect.
Having said that, collecting useful aliases (e.g. one, who, ...) in
contrib/ or in the wiki would be helpful.
From: Ondrej Certik <hidden> Date: 2016-06-15 22:47:03
On Thu, Jul 9, 2009 at 2:58 AM, Luciano Miguel Ferreira
Rocha[off-list ref] wrote:
On Thu, Jul 09, 2009 at 09:00:30AM +0200, Andreas Ericsson wrote:
quoted
Ondrej Certik wrote:
quoted
Hi,
coming to git from mercurial and svn, here is the alias part of my
.gitconfig:
[alias]
ci = commit
di = diff --color-words
st = status
co = checkout
And all is fine until I share commands to checkout my branch (for
example) with other people, then basically I have to write those
commands in full (e.g. commit, checkout, ...), since I cannot assume
they have their .gitconfig setup the same way I do. Especially for
people who are new to git.
What is the view on this in the git community?
Personally I think "plain" aliases like you use above are evil.
git is not svn or mercurial. If you use it like svn you'll be
surprised sooner or later and your workflow will feel awkward or
just plain wrong. hg and git are very similar, but the fact that
hg assumed the svn shorthands implies to me that they've tried
to retain a compatibility that does not, in fact, exist.
No, it just means that shorting common commands is useful and common.
quoted
I have no simple aliases for any of the commands. There's just no reason
for them since tab completion works so well.
"Intelligent" bash completion always gets in my way, so I can't use it.
I vote yes.
Thanks everyone for contributing to the discussion. So it seems that
most people are against such aliases.
I only want to correct one thing --- I use git exactly because it's
not svn and exactly because it's not mercurial, things like git
branches, git remote branches, rebase -i, are still truly unique, and
in my experience once one tries it, he never wants to come back.
That said, I do use "git ci" and "git st" very often and I don't think
it infers any kind of workflow. TAB completion doesn't help, because I
need to write "git stat<TAB>", e.g. I save exactly one letter., commit
is better, there I just need "git com<TAB>", but I am still faster
with my aliases. Maybe "git co" is nasty, but I never had any problems
with that either.
Ondrej