Sebastian Schuberth <> writes:

>> Every argument against default aliases was basically refuted, yet my
>> patches went nowhere. And the users still expect these aliases.
> +1 about having default aliases in general, and I'd also add these:

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).

If we squat on "co" and other short-and-sweet friends by adding them
as built-in aliases (i.e by adding them to git.c:commands[]), the
only effect would be to annoy people who have them defined somewhat
slightly differently, so that won't fly well.

> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to