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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 24, 2006, 21:38 UTC
Message-ID: <Pine.LNX.4.64.0612241602060.20138@iabervon.org>
In-Reply-To: <Pine.LNX.4.64.0612221709380.18171@xanadu.home>

On Sat, 23 Dec 2006, Nicolas Pitre wrote:

Show 19 quoted lines

> 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*