Re: What is missing from Git v2.0

Sebastian Schuberth <sschuberth@gmail.com> writes:

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.