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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 30, 2006, 23:02 UTC
Message-ID: <7vlklsfsgz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0611301624430.9647@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

> Wonderful! We might be converging to something then.

Yup. And it appears that we even agree that "intent to add" is a bad idea ;-).

Show 8 quoted lines

>   Here's a twist.  If you do "git commit <file1> <file2> ..." then 
>   only the  changes belonging to those explicitly specified files will 
>   be committed, entirely bypassing the current "added" changes.  Those
>   "added" changes will still remain available for a subsequent commit.
>
>   There is a twist about that twist: if you do "git commit -i <file>..." 
>   then the commit will consider changes to those specified files 
>   _including_ all "added" changes so far.

I sense that you are inviting me to argue for reverting the other "git commit" braindead which is spelled "--only" (and worse yet, it is the default). I am very tempted.

Show 11 quoted lines

>   But for instance it is best to only remember "git add" + "git 
>   commit" and/or "git commit -a".
>
> Doesn't it sounds nice?  The index is being introduced up front without 
> even mentioning it, and I think the above should be fairly palatable to 
> newbies as well.  Would only lack some enhancements to the commit 
> template and the "nothing to commit" message so the user is cued about 
> the fact that "current changeset is empty -- don't forget to 'git add' 
> modified files, or use 'git commit -a'".
>
> What do you think?

Other than these "twists", I think it makes sense, and that is what I think.

But making sense to me does not necessarily validate that a tutorial document is great for its intended audience, since I lost git virginity long time ago. I can only endorse that the description is technically accurate.