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

[Daniel Barkalow <barkalow@iabervon.org>]

On Sat, 23 Dec 2006, Nicolas Pitre wrote:

> On Fri, 22 Dec 2006, Carl Worth wrote:
> 
> > On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:
> > > On Thu, 21 Dec 2006, Carl Worth wrote:
> > >
> > > > 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*