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

[Nicolas Pitre <nico@cam.org>]

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

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

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

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