Sebastian Schuberth <sschube...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to