Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

From: Nicolas Pitre <nico@cam.org>
Date: Nov 29, 2006, 18:08 UTC
Message-ID: <Pine.LNX.4.64.0611291234350.9647@xanadu.home>
In-Reply-To: <7vr6vmsnly.fsf@assigned-by-dhcp.cox.net>

On Tue, 28 Nov 2006, Junio C Hamano wrote:

Show 10 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > This argument has its converse.  What you should _not_ have to worry 
> > about all the time is whether your index really includes all the changes 
> > you want included in your next commit.
> 
> That's what we have "git diff" with various output options for;
> I often do "git diff --stat" or "git diff --name-status" when I
> know I am about to commit in a dirty working tree.  I suspect
> that I am not getting your point.

I'm afraid this conversation is getting nowhere then.

Show 6 quoted lines

> > And whether wanting to leave local changes in the working directory 
> > without commiting them actually happen more often than wanting to commit 
> > every changes is arguable.
> 
> I do not think anybody is talking about which happens more
> often.

But I do.

Show 6 quoted lines

> "screw the index" people do not have to worry about the
> index during the course of their changes in the working tree
> toward the next commit, and the only time they need to tell git
> (which _IS_ a system based on the index, dammit) about what they
> want to do with the index is at the commit time, and they tell
> git to "screw the index" by passing "-a" to "git commit".

No one talked about "screw the index" people. Those are happily using Cogito.

We're talking about flattening the GIT learning curve. And as futile it may seem to you that newbies should just use "commit -a" without thinking, they still get bothered by that -a there. And probably they'll forget about it once in a while and then GIT will _appear_ as malfunctioning to them.

Of course amongst those newbies that didn't went away at this point there will be those who decide to study further and come to the index concept. And I hope that we all agree that the index is a powerful but still advanced concept that should not be presented up front.

But my point is: why not making a very little change to the default commit behavior. Really little change involving -a being the default. The impact on newbies will be significant as they won't have to grok everything at once to make sense of this -a we are telling them to use blindly. And it will sort of match known expectations to commit everything dirty.

And actually my point above is that in many cases, maybe the majoryty of those case but this is arguable, what one is doing is not keeping dirty and uncommited state around but rather committing every changes all the time. In _that_ case, which might not be all the time but often enough, then using -a is annoying[1].

So having -a the default makes GIT much more friendly to new users. You "add" files, you "commit", you edit some files, you "commit" again, and everything works fine, and you are happy and starts feeling good about GIT.

Now for those who've seen the light and want to use the index it is not much of a bother to add a -i to their commit invokation. At this point if you understand the index you know what you're doing, and using -i won't bother you as much it bothered you to use -a without knowing why when you was a newbie.

But still, if you are a GIT old fart and have difficulties switching habits, or if you simply are the kind with dirty not-to-commit state in your tree and adding -i all the time bothers you just like [1] above, then there is a way out! You are a GIT expert at this point of course and certainly know how to add an alias for the -i to be implicit with your "commit".

Therefore I think this is much more logical to ask the experts to add an alias for "commit -i" than asking such tricks from less experienced users. This is all my point is about.