Re: What is missing from Git v2.0

[Theodore Ts'o <tytso@mit.edu>]

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