Re: Separating "add path to index" from "update content in index"

On Sat, 23 Dec 2006, Nicolas Pitre wrote:

On Fri, 22 Dec 2006, Carl Worth wrote:

quoted

On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:

quoted

On Thu, 21 Dec 2006, Carl Worth wrote:

quoted

So, I think what I really want here is a complete separation in the
interface between adding a path to the index and updating content into
the index.

Strangely enough I think this separation is unnecessary and redundent.

One argument I would make in favor of the separation is that the two
operations are conceptually distinct from the user point-of-view. But
that's really hard to nail down since all users have different points
of view and different conceptual models,

... and if we want to break the CVS model and give people a better 
chance of ever grasping the git index concept I think they should not be 
different.

I don't think the misunderstanding (if there is one) of the git index 
model is due to CVS. If I'm using a staging area for wrapping Christmas 
presents, I may assign space to items I haven't got yet: this is where I 
put the tape so I can reach it, this is where the roll of wrapping paper 
goes, here is where the wrapping paper will be spread out, but I can't 
spread out the wrapping paper until I have the present (it just rolls back 
up), so there's nothing in the spot allocated to actual wrapping. Git 
reminds me of people who have to put a trash can in their parking spaces 
when their cars aren't there to keep them from being deallocated simply 
because they're empty.

The allocation of empty space before anything is put in it is a 
fundamental operation available in the general concept of a staging 
area. Someone coming from an index-based version-control system that 
doesn't lack this feature would expect to have a possible status:

# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#       new file: new-test-file
#

(And note that it can't be CVS-damage, because "Changed but not updated" 
isn't supported by CVS. This is a way in which git sort of has CVS-damage, 
because the "new file" operation goes straight to "Updated but not checked 
in", unlike everything else.)

	-Daniel
*This .sig left intentionally blank*