Sebastian Schuberth <sschuberth@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html