Re: [PATCH v3] build: add default aliases

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>> > It seems[1] that some
>> > people define "ci" as "commit -a", and some people define "st" as
>> > "status -s" or even "status -sb".
>> 
>> These option variants aside.
>> 
>> Just like thinking that committing must be the same as publishing,
>> it is a cvs/svn induced braindamage to think that "checking in" must
>> be the same as "committing".  The former is a sign of not
>> understanding the "distributed", the latter "the index".
>> 
>> In a world with both check-in and commit as two words usable to
>> denote possibly different concepts, it may make sense to say "you
>> check-in the current status of the working tree files into the
>> index, in order to make commits out of it later".
>
> Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are
> just wrong. So you are saying they are just ignorant.

I am sick of seeing my word twisted, especially when they were not
even addressed to you (see the message's primary recipients list).
Those who want to type "git ci" due to their familiarity with "svn
ci" are not wrong; they can do so if they choose.

Let's try again (see below).

> Now, if you are commenting on the aliases, that would mean you are not against
> the idea of aliaes per se, but more about values of those aliases. So if we
> agreed on the right values, you would welcome this patch.
>
> Is that correct?

No.

I agree with the issue the message I was replying to raised. The
alias mechanism is a way to help users to define their own
convenient short-cut. If you want to say "git ci" to mean "git
commit" (and not "git commit -a" or something else), define it for
your own use, and stop there, without getting in the way of other
people. That is why I see an attempt to add hard-coded set of
aliases as a move in the wrong direction.

A set of hard-coded alias that _officially_ declares that "checkin"
is an equivalent to "commit" has another issue.  It will close the
door for us to later add "git checkin" that may mean something
different from "git commit", and that is another reason why I do not
agree with the patch under discussion in this thread. A "checkin"
that is an operation that checks-in the current contents to the
index is one example of an action other than committing that the
word may make sense for, because "git checkout README.txt" is about
checking out of the index, its logical opposite "checkin" could be
about checking into the index.