Re: What is missing from Git v2.0

[Junio C Hamano <gitster@pobox.com>]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>>> If we don't standardize this now people will come up with their own
>>> definitions [1] [2] (and many others if you just search GitHub) which
>>> are again likely to differ (slightly), hindering interoperability.
>>
>> I am afraid that that ship has sailed long time ago, though.
>
> That's most likely true, but it does not get better by postponing this
> even more.

As I already said:

    I think it might be OK to implement them as the lowest priority
    fallback alias, so that '[alias] co = "user's definition"'
    anywhere in the various configuration locations will override
    it.  I am a bit hesitant about adding start-up overhead, though.
    Also I am not sure if people can agree with (1) a broadly wide
    selection of aliases and (2) the actual definitions for them (I
    am OK with "co === checkout" myself, but I'd rather not to even
    think about my Git wasting cycles parsing extra configuration
    items to support "br === branch" at all, for example).

I am not fundamentally opposed.  I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.

A few thinking points that are necessary to be worked out, even
before we start imagining a plan to introduce them, off the top of
my head, are these:

 * Should we add many random aliases, or should we limit ourselves
   only to a narrow set that everybody can agree on?

 * What is the additional cognitive load do we feel comfortable
   burdening with the new users?

 * What is the exact mechanism to give these built-in aliases?

Imagine that somebody says "[alias] ci = commit" and a handful of
vocal people on this list agree that it is a good idea.  Many random
websites start mentioning "git ci -a" in their beginner examples.

Users are led to think "ci" is a command just like "commit" and does
the same thing.  Some of them want to always commit everything
before moving to their next task, and want to alias it further, e.g.
"[alias] ci = ci -a"---which would not work.  At that point, the
users need to learn the distinction between native subcommands
(e.g. "commit"), built-in fallback aliases (e.g. "ci") and aliases
of their own in their ~/.gitconfig, and need to learn that only the
first kind and not the second kind cannot be used to define their
own alias (and the users need to learn "commit" at that time as
well).

That could be solved by making "ci" not a built-in fallback alias,
but a new subcommand (then there is no "'foo' in 'git foo' could be
a command or a built-in alias and they behave differently" issue),
and additionally somehow allowing a native subcommand overriden by
end-user alias, but I do not think anybody designed how such an
override would work so far.

So even if we agree that it would be a good idea to have some
default fallback aliases, the set of such aliases we ship must be
limited to a set that everybody can agree on, both in the sense that
"adding alias XX is good" and also in the sense that "alias XX must
be defined as YY".

As you allueded to, the Git userbase is a lot larger than it used to
be back in 2006, one alias, e.g. "[alias] br = branch", that is
reported as either useless or needed to be further tweaked by a
person on this list would mean that we would be either spending
unnecessary start-up cycles (for "useless" case) or adding cognitive
load of having to differente between "branch" and "br" (for "needs
further tweak" case) for thousands of users who would be better off
if we didn't have that specific alias.

So while I understand the desire to have a bit more handholding and
am not fundamentally opposed to the desire, I am not optimistic that
an attempt to implement these "aliases" would result in a very
useful addition to the system, even if done after careful thought.

In any case, this definitely is not a 2.0 material.  I agree that it
would be good to start discussing it early (rather than later) if we
ever want to do such a change.