Re: [PATCH v3] build: add default aliases

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> 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).

When you send messages to a public mailing list, even if not addressed to that
mailing list, is with the expectation that other people in that mailing list
will reply.

When you say something is a sign of not understanding, that means ignorance,
and there's nothing bad about that, we are all ignorant about many things.

> Those who want to type "git ci" due to their familiarity with "svn
> ci" are not wrong; they can do so if they choose.

I never suggested they were wrong, you suggested they were ignorant.

And this is being used by you as reason *not* to use ci as an alias for commit
by default.

> > 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.

A set of default aliases doesn't get in the way of other people either.

That's why all VCS tools have them, and none of them have a problem.

> That is why I see an attempt to add hard-coded set of aliases as a move in
> the wrong direction.

They are not hard-coded, they are configurable.

> A set of hard-coded alias that _officially_ declares that "checkin"
> is an equivalent to "commit" has another issue.

No. Nobody said anything about check-in, it's ci, which could be CommIt. And
you are conveniently ignoring all the other possible aliases for commit.

> 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.

Nobody said anything about a check-in. This is a red herring.

Absolultely nothing you have said in this second half has anything to do with
the question I asked. I asked specifically about the idea of aliases,
independently of their actual values, and all you have done is argue against
the value of a single alias: ci.

-- 
Felipe Contreras