Junio C Hamano wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > > > Junio C Hamano wrote: > >> Jeff King <p...@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 -- 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
