Junio C Hamano wrote: > Sebastian Schuberth <sschube...@gmail.com> writes: > > > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gits...@pobox.com> wrote: > > > >>> 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. > > > > That's most likely true, but it does not get better by postponing this > > even more. > > 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.
You are probably biased in that you've used Git far much more than the average user has (or future new users). > 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. I think it's reasonable to follow these guidelines: 1) Each default alias should have two characters 2) Each default alias should map to a command without arguments 3) Each default alias be widely used in the wild This set matches the above: co = checkout ci = commit rb = rebase st = status br = branch dt = difftool mt = mergetool You might not like 'br', but there's tons of people already using that alias, so it's not "useless". I can go find links to many examples if you would like. > 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. The fact that you are not optimistic about it doesn't mean it's impossible. > 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. Why is not material for v2.0? Because you say so? Are you going to wait another ten years to introduce this to v3.0? This is actually the perfect time to do it. -- Felipe Contreras -- 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
