Junio C Hamano wrote:
> Junio C Hamano <gits...@pobox.com> writes:
> > 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.
> >
> > A few thinking points that are necessary to be worked out, even
> > before we start imagining a plan to introduce them, off the top of
> > my head, are these:
> >
> >  * Should we add many random aliases, or should we limit ourselves
> >    only to a narrow set that everybody can agree on?
> >
> >  * What is the additional cognitive load do we feel comfortable
> >    burdening with the new users?
> >
> >  * What is the exact mechanism to give these built-in aliases?
> >
> > Imagine that somebody says "[alias] ci = commit" and a handful of
> > vocal people on this list agree that it is a good idea.  Many random
> > websites start mentioning "git ci -a" in their beginner examples.
> >
> > Users are led to think "ci" is a command just like "commit" and does
> > the same thing.... and need to learn that only the
> > first kind and not the second kind cannot be used to define their
> > own alias (and the users need to learn "commit" at that time as
> > well).
> A bit further on this point, looking into the future.
> It might help if we added some "introduction" phase to the first
> invocation of "git init", "git clone", etc. that is interactively
> run on a machine where there is no $HOME/.gitconfig detected, and
> help the user populate it with a few selected and uncontroversial
> ones.  Such a session might go like this:
>       $ git init
>         ... We do not see $HOME/.gitconfig; using Git for the first time?

We shouldn't say $HOME/.gitconfig, that's not user friendly, and it might not
be accurate.

Plus, we might prefer $XDG_CONFIG_HOME/.config/git/config.

"There doesn't seem to be a Git user configuration." is enough.

>         >> Do you want us to add a few sample aliases to your configuration 
> file?
>         Y

I don't see the point in asking this, just put them, the user can remove them
if he doesn't want.

>         ... Done.  You can further tweak $HOME/.gitconfig to suit
>         ... Git to your taste.

Aagain not friendly. `git config --global --edit`.

> And it would end up with something like this:
>       $ cat $HOME/.gitconfig
>         [user]
>               name = <<interactively ask and record the result>>
>                 email = <<ditto>>
>       [alias]
>               co = checkout
>               lg = log --oneline
> which can serve as an example the user can then tweak, without
> giving any false impression that "co" is any more special than
> whatever the user adds as a custom alias.

You are assuming the user wanted to "further tweak", most likely he didn't, in
which case he wouldn't have seen those aliases.

It would be more friendly if the aliases are always there, then we can mention
them in the documentation of the relevant commands.

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

Reply via email to