Nicolas Pitre wrote:
quoted text
> On Thu, 30 Nov 2006, Junio C Hamano wrote:
> 
>> Nicolas Pitre <nico@cam.org> writes:
>>
>>> ...  But let me repeat my last question:
>>>
>>> Would it make sense for "git add" to do the same as "git update-index" 
>>> on already tracked files?  Given the explanation above this would make 
>>> 100% sense to me.
>> I think this makes sense and what we did in the original "git
>> add".
> 
> Wonderful! We might be converging to something then.
> 
> Because, conceptually, it then becomes much easier to tell newbies about 
> the index as follows (this could be pasted in a tutorial somewhere):
> 
>   Contrary to other SCMs, with GIT you have to explicitly "add" all
>   the changes you want to commit together.  This can be done in a few
>   different ways:
> 
>   1) By using "git add <file_spec...>"
> 
>      This can be performed multiple times before a commit.  Note that 
>      this is not only for adding new files.  Even modified files must be
>      added to the set of changes about to be committed.  The "git 
>      status" command gives you a summary of what is included so far for 
>      the commit.  When done you should use the "git commit" command to
>      make it real.
> 
>      Note: don't forget to "add" a file again if you modified it after 
>      the first "add" and before "commit". Otherwise only the previous 
>      "added" state of that file will be committed.
> 
"This is because git tracks content, so what you're really 'add'ing to 
the commit is the *content* of the file in the state it is in when you 
'add' it."


quoted text
>   2) By using "git commit -a" directly
> 
>      This is a quick way to automatically "add" all modified files to 

.. "add" all tracked and modified files to ...

quoted text
>      the set of changes and perform the actual commit without having to 
>      separately "add" them.  This will not "add" new files -- those 
>      files still have to be added explicitly before performing a commit.
> 
>   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.
> 
>   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?
> 

me likes

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
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