Nicolas Pitre <nico@cam.org> writes:

quoted text
> Wonderful! We might be converging to something then.

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

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

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html