On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote: > > 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). I think Junio has a really strong point. If the goal is to make life easier for new users, allowing them to save a few keystrokes is probably not the most significant thing we can do. And we have to balance this with the additional cognitive load in remembering how a particular two character alias maps to the "real" command. This is especially true for commands which might not be used as often -- e.g., "rebase", and for commands where the meaning of "git commit" without any argument is qualitatively different from what "ci" (for checkin) means in most other source management systems. So I do think it's worth thinking about this very carefully. For certain, I would **not** recommend using shortcuts in example command sequences. If the user reads "git rebase" or "git cherry-pick" it means a lot more than if they see a series of apparent chicken scratches filled with things like "git rb", "git pi", "git st", etc. In fact, to be fair, you may be getting biased because you're used to using the two character shortcuts, so for you, of *course* "rb" and "pi" and "ci" make a lot of sense. But for someone who is starting from scratch, I really question how much it helps, and how much it might hurt, to see the two character shortcuts or even to have to remember the two character shortcuts. And for a command like "rebase" where the user can very easily shoot themselves in the foot to begin with, I'd actually suggest that it's a _good_ thing that they have to type it out in full. - Ted -- 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