Thread (24 messages) flat view 24 messages, 7 authors, 2016-06-15

Re: [PATCH v3] build: add default aliases

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:58:56

On Sat, Sep 28, 2013 at 10:18 PM, Michael Haggerty [off-list ref] wrote:
On 09/29/2013 12:41 AM, Felipe Contreras wrote:
quoted
On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder [off-list ref] wrote:
quoted
quoted
On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
quoted
For now simply add a few common aliases.

  co = checkout
  ci = commit
  rb = rebase
  st = status
[...]
quoted
But making 'ci' a synonym of another command by default while still
keeping its definition configurable would be doing people a
disservice, I fear.
And I and many (most) users disagree.
quoted
As long as 'ci' works out of the box, it will
start showing up in examples and used in suggestions over IRC, etc,
which is great.
...and in scripts.
quoted
It might, or...
quoted
Unfortunately that means that anyone who has 'ci'
defined to mean something different can no longer use those examples,
that advice from IRC, and so on.  So in the world where 'ci' is a
synonym for 'commit' by default, while people still *can* redefine
'ci' to include whatever options they like (e.g., "-a"), actually
carrying out such a personal customization is asking for trouble.
Precisely for this reason it might not. If people know aliases can be
different in different machines, they would avoid them in
documentation which is meant for all machines.
My experience contradicts your prediction.  I have 'ci'/'co' aliases in
my own configuration.  But even though I am aware of the fact that other
people might not have the same aliases, I have on multiple occasions
used them in documentation and/or scripts meant for other people.  The
muscle memory is just too strong.
If you are already making that error, then this patch wouldn't make it
any worst. In fact, it would make the situation better.

If previously you had 10 persons complaining about the "ci" command
not working, now 9 of them wouldn't complain because "git ci" does
actually work, even if you have aliased it to something slightly
different, like "commit -v". Instead, you would have 1 person
complaining, because he has a different alias, which makes the command
fail somehow. In reality, that 1 person might not even exist.

The solution before and after my patch is the same; avoid the 'ci'/'co' aliases.
My error was discovered by other people who didn't have those aliases.
And after this patch it still will.
If *most* people had the same aliases as I did, and others had defined
their own slightly different ones, then the scripts would have subtly
malfunctioned for the latter set of users and I would have had trouble
reproducing the errors.
Doubtful. But a warning that a default alias is being used, or simply
showing the actual command in the standard output would fix the
problem.

It certainly looks like you are not even looking for solutions for the
hypothetical problems you put forward.
So, even though I think such aliases are a great convenience factor, I
am -0 on including pre-defined but overrideable aliases and -1 on
including pre-defined and non-overrideable aliases.
And still, somehow every other VCS out there manages default aliases
just fine, and Mercurial even allows overriding commands. How do you
explain that the world hasn't ended for them?

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help