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,
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   (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